Vorteile von Nicht-Web-Applikationen?
-
Wenn du eh mit C# arbeitest, wieso kombinierst du nicht beides
EDIT:
Hab mal ein VideoCast von Microsoft gesehen, dass man DotNet-Anwenungen zentral deployen kann. Genauso wie Java Web Start Anwendung. Aber das ist schon etwas her. Mit Erkennung von neue Versionen und Differenzpatching.
-
Spontan sieht mir das sehr nach einer Web-Applikation aus. Allerdings:
- Könnte ich mir schon Kompatibilitätsprobleme vorstellen. Ist es nicht so, dass sich die Browser (etwa in Bezug auf JavaScript und CSS) erheblich unterscheiden? Ich bin definitiv kein Web-Entwickler, habe aber bei Kollegen schon öfter mitgekriegt, dass sie damit echte Probleme hatten.
- Kannst du Sicherheitsprobleme wirklich in den Griff kriegen? Ich denke da einerseits an Angriffe auf den Server (auch über deine Scripte). Andererseits aber auch an die Sicherheit der Daten, die an die Mitarbeiter ausgeliefert werden. Eine für's Controlling ausgelieferte Liste der Umsätze des letzten Jahres aus dem Browser rauszukrigen, stelle ich mir trivial vor.
- Ist es wirklich so erstrebenswert, dass Mitarbeiter von überall aus auf die Daten zugreifen können? Ich denke da an den Browser-Cache, die History und ähnliches. Und das in einem Internet-Cafe oder bei einem Kunden!
Dass die Kommunikation zwischen Client und Server bei Web-Applikationen billiger als bei Fat Clients ist, glaube ich nicht. Zumindest bei einer 3tier-Applikation überträgst du nur die wirklich benötigten Daten und die am besten komprimiert. Ein weiterer Vorteil einer solche Applikation könnte auch der bessere Schutz von DB-Zugriffen sein.
Dass die Rechenlast beim Server liegt, sehe ich nicht als Nachteil an. Da gehört sie doch auf jeden Fall hin.
Stefan.
-
Zeus schrieb:
EDIT:
Hab mal ein VideoCast von Microsoft gesehen, dass man DotNet-Anwenungen zentral deployen kann. Genauso wie Java Web Start Anwendung. Aber das ist schon etwas her. Mit Erkennung von neue Versionen und Differenzpatching.Das wäre ja sehr interessant, hast du den Webcsat noch?
MfG SideWinder
-
Yup habs wiedergefunden:
https://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=118764814Windows Presentation Foundation (Teil 4-4) - Smart Client mit WPF gehalten von Dirk Primbs
ClickOnce Deployment
-
Also ein Fatclient ohne Server kommt imo nicht in Frage. Die DB Zugangsdaten würden auf dem Client liegen und wären somit nicht sicher.
Du solltest Dich also entscheiden zwischen Application-Server + Fatclient oder Application-Server + Webclient. Der Server bietet dabei ja durchaus noch weitere Vorteile. Du kannst z.B. Daten zentral cachen, um DB Abfragen (die ja häufig das Nadelöhr darstellen) einzusparen. Und Du kannst teure Operationen (solltest Du Dich für einen Fatclient entscheiden) auf den Server auslagern. Ausserdem kannst Du viel einfacher Jobs schedulen, also z.B. zu niedrigen Stoßzeiten irgendwelche Reports generieren usw.
Die Vor- und Nachteile hast Du ja schon gut zusammengefasst. Ich sehe bei Deinen Anforderungen allerdings keinen Grund, durch den sich ein Fatclient aufdrängen würde. Im Grunde wirds ja lediglich ne Datenschleuder werden (Daten eingeben, Daten ausgeben), die Paradedisziplin von Webclients.
-
Also ein Fatclient ohne Server kommt imo nicht in Frage. Die DB Zugangsdaten würden auf dem Client liegen und wären somit nicht sicher.
Klar, davon hat ja auch niemand gesprochen.
MfG SideWinder
-
general bacardi schrieb:
hustbaer schrieb:
Nein.
Es ist Fakt, dass Web-Applikationen für grosse, komplizierte User-Interfaces nicht zu gebrauchen sind.Dann sieh dich mal im Internet um. Du hast wohl noch nicht lange Internet?
Ausserdem sollten User Interfaces nie kompliziert sein. EIn kompliziertes UserInterface ist immer ein schlechtes User Interface.hustbaer schrieb:
Anders gesagt: ich bin was diesen Punkt angeht nicht Skeptisch, ich *weiss* dass es nicht gescheit funktioniert.
Weil Du es selber noch nie hingekriegt hast
Achherrjeh, ein Mister Schlau (tm).
Ja, natürlich, du hast Recht, und ich erst seit gestern Internet.
-
Nachtrag:
Twitter geht nach DoS-Angriff in die Knie. Dieser Beitrag war Ausloeser und keine Ahnung, ob es schon gesagt wurde. Webanwendungen sind anfaelliger gegenueber Stoerungen im allgemeinen. Das muss jetzt nicht zwingend eine boeswillige Attacke sein. Die Verteilung einzelner Daten ist wesentlich einfacher als eine Userinterfacekommunikation uber das Netzwerk. Wer oefters mit Linux arbeitet und remote GUI-Anwendungen ueber "ssh -X ..." kennt das vielleicht, dass man da schon eine ordentliche Leitung haben sollte.
-
knivil schrieb:
Die Verteilung einzelner Daten ist wesentlich einfacher als eine Userinterfacekommunikation uber das Netzwerk.
Es ist wesentlich einfacher, eine Webanwendung auf einem Server zu deployen als eine Clientanwendung auf tausend Clients zu installieren und sich ggf. noch mit clientspezifischen Problemen rumärgern zu müssen.
Ist aber im Grunde auch irrelevant und offtopic. Denn es wurde schon gesagt, dass hier Daten von einem zentralen Server bereit gestellt werden müssen. Es stellt sich also gar nicht die Frage, ob Webanwendung oder Offline-Client.
-
Und der Browser ist kein Client und muß nicht auf tausende PCs installiert/aktualisiert werden? Der bleibt statisch für 20 Jahre.
-
Willkommen im 21. Jahrhundert, wo ein Browser faktisch zur Standardinstallation einer Workstation gehört.
Natürlich gibts auch Browserunterschiede beim Implementieren von Webanwendungen. Aber es gibt längst leistungsfähige Libraries, die darüber abstrahieren. Die Entwicklung von Webanwendungen ist extrem technologie-getrieben und bei den Technologien gehts rasant vorwärts, offenbar wesentlich schneller als es die Köpfe vieler Forenuser hier erreicht.
-
[quote="byto"]
knivil schrieb:
Es ist wesentlich einfacher, eine Webanwendung auf einem Server zu deployen als eine Clientanwendung auf tausend Clients zu installieren..
klar, und wenn der server ausfällt können alle 1000 clients nix dagegen tun.
Artchi schrieb:
Und der Browser ist kein Client und muß nicht auf tausende PCs installiert/aktualisiert werden? Der bleibt statisch für 20 Jahre.
browser sind meistens schon dabei, wenn das OS installiert wird. ausserdem wollen viele ins internet um pornos zu gucken und so. allein dafür brauchen sie schon 'nen browser.
-
Ich habe "installiert/aktualisiert" geschrieben. Schön und gut wenn ein Browser mit dabei ist. Aber der muß auch aktualisiert werden, oder? Und eine Aktualisierung kann die selben Schwierigkeiten bereiten, wie eine Installation. Der Installations- und Update-Vorgang selbst ist doch nicht das Problem, es sind doch Inkompatibilttäten oder allgemein Bugs die im Browser auftreten können. Ich weiß jetzt nicht, wo ein Update unkritischer sein soll, als eine Installation?
Wo ist mit einem Browser Software "verschwunden"? Der Browser selbst ist ein Richclient.
-
Artchi schrieb:
Ich habe "installiert/aktualisiert" geschrieben. Schön und gut wenn ein Browser mit dabei ist. Aber der muß auch aktualisiert werden, oder?
Nö, wozu? Der Webanwendung ists grundsätzlich wurscht, solange die aktuellen Web Standards unterstützt werden.
-
Artchi schrieb:
Ich habe "installiert/aktualisiert" geschrieben. Schön und gut wenn ein Browser mit dabei ist. Aber der muß auch aktualisiert werden, oder?
kommt drauf an. im extremfall machste den server so, dass html 3.2 ausreicht. das packen auch noch uralt-browser.
Artchi schrieb:
Und eine Aktualisierung kann die selben Schwierigkeiten bereiten, wie eine Installation.
nee, das passiert fast automatisch. bei firefox z.b. geht das ziemlich stressfrei.
Artchi schrieb:
Wo ist mit einem Browser Software "verschwunden"? Der Browser selbst ist ein Richclient.
'nen webbrowser hat erstmal fast jeder, genau so wie unter unixoiden systemen jeder irgendwelche x-clients hat. das client/server-prinzip ist schon nicht schlecht: der server stellt irgendwelche funktionalitäten zur verfügung und das user-interface rendern die clients.
-
byto schrieb:
Artchi schrieb:
Ich habe "installiert/aktualisiert" geschrieben. Schön und gut wenn ein Browser mit dabei ist. Aber der muß auch aktualisiert werden, oder?
Nö, wozu? Der Webanwendung ists grundsätzlich wurscht, solange die aktuellen Web Standards unterstützt werden.
Und Webstandards bleiben 20 Jahre auf dem selben Stand? Oder warum gibts immer neue Browserversionen und neue Plug-ins/Add-ons für Browser? Wir arbeiten alle mit HTML 1.0, ohne Flash, ohne SVG, ohne XYZ. Und das W3C arbeitet nicht an neuen Standards?
Kommt, ihr belügt euch doch selber! Andauernd kommt was neues raus, wo man den Browser aktualieseren muß. Oder ein anderer browser unterstützt Funktion X, weil der andere Brwoser Funktion X erst in ein paar Monaten unterstützt. Und wenn mir jetzt jemand sagt, das man das nicht muß, weil man nicht das neueste braucht, dann viel Spaß mit "modernen" WebApps!
-
;fricky schrieb:
nee, das passiert fast automatisch. bei firefox z.b. geht das ziemlich stressfrei.
Ach, guck an?! Der Richclient namens Firefox aktualisiert sich stressfrei. Warum soll das nicht mit jedem anderen Richclient gehen?
Den Update-Mechanismus kannst du auf jede andere zu installierende Software anwenden.
-
Artchi schrieb:
Und Webstandards bleiben 20 Jahre auf dem selben Stand? Oder warum gibts immer neue Browserversionen und neue Plug-ins/Add-ons für Browser? Wir arbeiten alle mit HTML 1.0, ohne Flash, ohne SVG, ohne XYZ. Und das W3C arbeitet nicht an neuen Standards?
Wenn ich z.B. einen Webclient mit GWT implementiere, dann liefert mir der GWT Compiler verschiedene browserspezifische Kompilate. Unter anderem ist da ein Kompilat dabei, das die Anwendung fehlerfrei im Internet Explorer 6 darstellt - ein Browser, der 2001 rauskam und dessen Support nächstes Jahr ausläuft.
Und jetzt willst Du mir erzählen, meine Webanwendung benötigt eine aktuelle Browserversion? Das ist einfach Blödsinn. Aber ich verstehe Deine Argumentation sowieso nicht. Natürlich sollte ein Browser mit der Zeit auch aktualisiert werden. Aber es ist nun mal ein Unterschied, ob ich eine Anwendung aktualisieren muss oder 1000. Zumal die Softwarequalität eines Browsers idR wohl deutlich höher ist als die Qualität einer Individualsoftware.
Wieviele Unittests gibts denn in Deinem Richclient Projekt, die die Softwarequalität sicherstellen? Und wieviele Unittests meinst Du, gibt es für aktuelle Browser?
-
Die Diskussion ist sinnlos, weil es für Richclient genau so eine Platfrom gibst, wie für das Web, aka .NET/Java (Inklusive ClickOnce Deployment und JavaWebStart).
-
Artchi schrieb:
;fricky schrieb:
nee, das passiert fast automatisch. bei firefox z.b. geht das ziemlich stressfrei.
Ach, guck an?! Der Richclient namens Firefox aktualisiert sich stressfrei. Warum soll das nicht mit jedem anderen Richclient gehen? Den Update-Mechanismus kannst du auf jede andere zu installierende Software anwenden.
von wegen. die installationsprozedur des FF haben dir andere schon abgenommen. den gibts z.b. für verschiedene OS. und wenn's nicht der FF sein soll, dann nimmste eben 'nautilus' oder sonstwas, geht ebenso. bei 'nem monolithischen softwareklotz, haste zig verschiedene binaries (vorausgesetzt du programmierst in C, C++ oder einer ähnlichen nicht-VM umgebung und nicht-portablen sprache(in bezug auf betriebssysteme)) und musst für jedes OS einen eigenen installer haben. das ist weit weniger lustig, als eine serverbasierte software zu schreiben, die über standardisierte protokolle und netze von fast jedem ort der welt aus benutzt werden kann. und updates sind auch viel einfacher, die einfach auf den server geschoben werden und jeder hat gleich die neueste version. klar hat sowas auch nachteile, die hier alle schon aufgelistet wurden, aber in manchen situationen ist client/server-basierte software einfach eine tolle sache. ich bin z.b. grundsätzlich für eine trennung von funktionalität und GUI und zwar so, dass netzwerktaugliche schnittstellen verwendet werden, d.h. client und server können, müssen aber nicht, entweder auf demselben rechner oder sonstwo laufen.
