Laden...

Clickonce vs. ASP.NET-Anwendungen

Erstellt von mosspower vor 15 Jahren Letzter Beitrag vor 15 Jahren 1.253 Views
mosspower Themenstarter:in
456 Beiträge seit 2007
vor 15 Jahren
Clickonce vs. ASP.NET-Anwendungen

Hallo "Kollegen",

ich möchte hier einmal eine Diskussion eröffnen, wann man und ob man überhaupt Clickonce-Anwendungen (hier meine ich eigenlich Windows-Applikationen, ob nun Forms oder WPF sollte egal sein) und wann ASP.NET-Anwendungen einsetzt werden sollten.

Bis vor kurzem habe ich ja immer Webanwendungen bevorzugt. Ich kannte zwar Java-Webstart, das sich aber nie so ganz durchgesetzt hat. Als ich soetwas bei uns im Unternehmen benötigte, bin ich auf Clickonce gestoßen. Auch habe ich privat zwei Anwendungen laufen, die mit Clickonce arbeiten. Also, ich finde diese Technologie als sehr gute Alternative für Webanwendungen. (Eigentlich sind ja die Clickonce-Anwendungen auch teilweise Webanwendungen).

Was spricht eigentlich dafür und was dagegen? Ich würde mal sagen, dass kleine Programme, wie z.B. Downloadprogramme, Administratoren usw. nicht unbedingt eine Webanwendung sein müssen, hier reicht doch völlig eine Clickonce-Anwendung aus.

Der Nachteil ist sicherlich, dass man, je nach Komplexität der Anwendung, einen eigenen kleinen Server programmieren muss, der die Anfragen entegennimmt und verarbeitet, wie es ja ein Webserver bei Webanwendungen macht.

Wie würdet ihr eigentlich auf die Datenbank gehen? Über "Umweg" einen Server (kleine Konsoleanwendung via z.B. WCF ect.) oder direkt auf eine Datenbank gehen (was ich noch nie gemacht habe, bzw. das sollte doch imo nicht gemacht werden, oder? ... das doch eine große Sicherheitslücke)

OK, die Diskussion ist eröffnet. Ich freue mich auf rege Teilnahme .. und danke schon einmal für eure Meinungen und Erfahrungsberichte im Voraus.

O
778 Beiträge seit 2007
vor 15 Jahren

Naja, ich würde es weniger von der Größe der Anwendung abhängig machen als vielmehr von der Häufigkeit der zu erwartenden Aktualisierungen. Wenn eine Anwendung nur ein- zweimal im Jahr aktualisiert werden muss, dann darf der Deploymentaufwand auchmal etwas höher sein. Wenn du jetzt was hast, was sich quasi täglich ändern kann dann Webanwendung. Der andere Punkt ist dann noch der mit den Betriebssystemen, wenn du garantieren kannst, dass aus deiner Zielgruppe alle Windows mit installiertem .NET Framework haben dann geht auch mal was clientseitiges.

Für mich gilt die Faustregel wenn nichts gegen Client spricht, dann Clientsoftware (und Deployment zB über ClickOnce), weil Clients i.d.R. einfacher zu programmieren und gleichzeitig mächtiger sind. Ansonsten halt Web.

2.187 Beiträge seit 2005
vor 15 Jahren

Hallo mosspower,

Das ist im endefekt die uhr alte Diskusion: Web-Anwendung gegen Desktop-Anwendung.

Es gibt nur 2 Gründe für Web-Anwendungen (die mir einfallen):

  1. Es soll wirklich eine Web-Seite werden und über's Internet erreichbar sein.
  2. Es soll auf verschiedensten Platformen ausgeführt werden. (Und dieser Grund wird mit den Passenden Frameworks für Desktopanwendungen (JVM, .NET CLR, ...) auch wieder hinfällig.)

Ansonsten kann man es ohne zögern als Desktop-Anwendung implementieren, da diese einfacher sind und benutzerfreundlicher. (Drag&Drop und Co.)

Ob man jetzt die Desktop-Anwendung als FatClient (direkt auf Datenbank) oder als Smart-Client (über Web-Service) oder als N-Tier-Anwendung entwickelt ist dan schon fast egal. (Auto-Up-Date-Funktonen zum Dank.)

[EDIT]Da hab ich wohl zu lange zum Posten gebraucht. Stimme onlingurke natürlich so weit zu.[/EDIT]

Gruß
Juy Juka

Gelöschter Account
vor 15 Jahren

es kommt immer darauf an, was du hast und was du brauchst.

brauchst du eine gui-lastige software. dann ist etwas clientseitiges zu erwägen. hast du aber schwache clients (überwiegend alte rechner), dann ist sowas wie ein applicationserver in erwägung zu ziehen.

hiervon gibt es beliebig viele kombinationen, die in der realisierungskombination beträchtliche unterschiede aufweisen können.

man kann also nichts pauschal sagen. bei konkreten anforderungen kann man auch konkreter werden.

5.941 Beiträge seit 2005
vor 15 Jahren

Hallo zusammen

@JuyJuka
Es gibt natürlich noch einen weiteren Vorteil...
Eine Webanwendung muss nur zentral - also an einem Ort - ein Update erfahren dass sich dann automatisch überall auswirkt.

Und zu deinem Punkt 2., scheinbar und theoretisch hinfällig, in der Praxis aber eher nicht.
Auch wenn sie theoretisch kompatibel sind, kann man nicht alles 1:1 umsetzen sonmdern muss zumindest irgendwo eine kleine Anpassung vornehmen, was das Deployment wiederum aufwändiger macht.

Ich sehe ClickOnce als eine Art der Installation und Aktualisierung, nicht als Art einer Anwendung.

Ansonsten kann ich Jack30lena zustimmen.
Es muss konkret abgewogen werden, was für ein Typ Anwendung und mit was für einer Infrastruktur gefahren wird.

Pauschal lässt sich sowas nicht optimal beantworten.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 15 Jahren

Naja, ich würde es weniger von der Größe der Anwendung abhängig machen als vielmehr von der Häufigkeit der zu erwartenden Aktualisierungen. Wenn eine Anwendung nur ein- zweimal im Jahr aktualisiert werden muss, dann darf der Deploymentaufwand auchmal etwas höher sein. Wenn du jetzt was hast, was sich quasi täglich ändern kann dann Webanwendung.

Hm, das verstehe ich jetzt aber nicht so ganz. Es ist doch völlig egal, ob ich fünfmal am Tag Änderrungen beim Webserver einspiele (ggf. ist der Server down, je nach Art der Einspielung) oder fünfmal am Tag der Client sich das neuste Update zieht, wo ist denn hier der Unterschied?

@All,

nehmen wir mal ein Beispiel. Im Lager soll es mehrere Abfertigungsprogramme für den Versand geben. Jetzt gibt es drei Möglichkeiten.

a) Webanwendung
b) Interne Remoting-Anwendung (Logik auf dem Server), wie nennt man das eigentlich? "Thin-Client" in Hochkommata? 😁
c) Fat Client (Logik auf dem jeweiligen Client)

B und / oder C sind dann doch, vorausgesetzt die arbeiten alle mit Windows, die bessere Lösung, da der Entwicklungszeitraum für Windowsapplikationen doch imo schneller geht. Auch sind die nötigen Funktionalitäten, bzw. Anforderungen schneller umzusetzen, als wenn man da zig AJAX-Lösungen reinmacht.

Imo sollte dann doch b hier immer die bevorzugte Lösung sein, oder? Bis vor kurzem hätte ich mich immer für Webanwendung entschieden.

Gelöschter Account
vor 15 Jahren

ja und nein. das ist bei weitem nciht konkret genug.

2.187 Beiträge seit 2005
vor 15 Jahren

Hallo,

Es gibt natürlich noch einen weiteren Vorteil...
Eine Webanwendung muss nur zentral - also an einem Ort - ein Update erfahren dass sich dann automatisch überall auswirkt.

Es ging ja garnicht um Vorteile. Und das zweite gillt auch für Desktopanwendungen, wenn sie Click-Once verwenden.

Und zu deinem Punkt 2., scheinbar und theoretisch hinfällig, in der Praxis aber eher nicht.
Auch wenn sie theoretisch kompatibel sind, kann man nicht alles 1:1 umsetzen sonmdern muss zumindest irgendwo eine kleine Anpassung vornehmen, was das Deployment wiederum aufwändiger macht.

Das Problem hat man nur, wenn man am Framework vorbei arbeitet. Die Frage ist, ob man wenn man das schon tun muss überhaupt noch die Wahl hätte eine Web-Anwendung zu machen. (Ich glaube, wenn man schon so tief in der Hardware/im Betriebssystem steckt, kann man ne Web-Anwendung getrost vergessen.)

b) Interne Remoting-Anwendung (Logik auf dem Server), wie nennt man das eigentlich? "Thin-Client" in Hochkommata?

Das ist ganz einfach eine n-Tier-Anwendung. Eine verteilte, mehrschichtige Anwendung. (Dann gibts noch nicht-verteilte, mehrschichtige Anwendungen und die "Klumpen"-Anwendungen 😉 )

Imo sollte dann doch b hier immer die bevorzugte Lösung sein, oder? Bis vor kurzem hätte ich mich immer für Webanwendung entschieden.

Auch nur wenn es keine gründe für eine Web-Anwendung gibt und man sich den Overhead und die Problem antuen will/muss.

Gruß
Juy Juka

5.941 Beiträge seit 2005
vor 15 Jahren

Hallo JuyJuka

Es ging ja garnicht um Vorteile. Und das zweite gillt auch für Desktopanwendungen, wenn sie Click-Once verwenden.

Vorteile / Gründe, im Grunde dasselbe.
Jein, bei ClickOnce musst du das Update überall einspielen, es geschieht einfach nur automatisch.

Das Problem hat man nur, wenn man am Framework vorbei arbeitet. Die Frage ist, ob man wenn man das schon tun muss überhaupt noch die Wahl hätte eine Web-Anwendung zu machen. (Ich glaube, wenn man schon so tief in der Hardware/im Betriebssystem steckt, kann man ne Web-Anwendung getrost vergessen.)

Oder ob das zweite Framework auf der zweiten Plattform evt. anders implementiert ist (Mono) und nicht das tut, was du erwartest.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

2.187 Beiträge seit 2005
vor 15 Jahren

Hallo Peter Bucher,

Oder ob das zweite Framework auf der zweiten Plattform evt. anders implementiert ist (Mono) und nicht das tut, was du erwartest.

Da muss ich meine Unwissenheit eingestehen, da ich bis jetzt in meiner hübschen, blauen .NET Welt lebe.

Gruß
Juy Juka