Hier wird ja leidenschaftlich diskutiert
Tatsache ist doch einfach, dass ich zuerst wissen muß, was erwartet der Kunde von einer Anwendung. In einem Pflichtenheft muß festgelegt werden, welche Anforderungen essentiell sind, welche wünschenswert und welche "nice to have". Dann kann man auch entscheiden, wie die Anwendung konzipiert werden muß. Die Entscheidung für die Programmiersprache spielt an dieser Stelle noch gar keine Rolle.
- Falls ein Programm auf lokale Ressourcen des Anwender-PCs zugreifen muß, muß es zumindest einen lokalen Teil geben, welcher z.B. mit der Peripherie des jeweiligen PCs kommunizieren kann.
- Falls hinter dem Programm eine Geschäftslogik steckt, welche unabhängig vom jeweils installierten Versionsstand der Anwenderschnittstelle aktuell sein muß, dann muß zumindest ein Teil der Funktionalität auf dem Server liegen
- Falls die Anwendung ohne Installation von jedem Rechner im Intranet aus erreichbar sein muß, muß das Programm vollständig auf dem Server liegen
Absolut portabel ist natürlich eine Webanwendung, welche im Browser ohne externe Plug-Ins läuft. In einem Intranet hat man zumindest den Vorteil, dass man im Allgemeinen eine homogene Browserlandschaft vorfindet. Man kann sich also an den üblicherweise vorhandenem Browser orientieren.
Damit verfügt man über einen "thin client", ohne eigene Intelligenz, nämlich den Browser, der nur Aus- und Eingabe der Daten abwickelt und die Formulare darstellt.
Der Nachteil ist, alle Daten müssen von der Server-Anwendung verifiziert werden. Auch wenn man eine Eingabeüberprüfung mit JavaScript implementiert - man kann sich nie darauf verlassen, dass der User es auch aktiviert hat. Alle Änderungen der Eingabemaske erfordern das Senden der Daten zum Server, welcher daraufhin die neue Maske zurückgibt. Das erhöht den Datenverkehr und die Serverlast. Berichte müssen auf dem Server in
HTML oder Pdf erstellt werden, um ggf. aus dem Browser heraus gedruckt zu werden.
Die Alternative ist ein "fat client". mit dem man bei der in Delphi ab Enterprise unterstützten Three-Tier-Anwendung ankommt. Man hat also eine lokale Anwendung, welche interaktive Veränderungen an der Benutzeroberfläche erlaubt, Reporting-Funktionen besitzt und die Eingabedaten lokal prüft und in ein für den Server vorhersehbares Format bringt.
Der Server wiederum dient als Applikationsserver. Er bearbeitet die Daten gemäß den aktuellen Geschäftsregeln und interagiert seinerseits mit der dritten Schicht, dem Datenbankserver. Außerdem steuert er das lokale Programm und liefert die jeweils aktuellen Regeln für die Benutzeroberfläche.
Eine lokale Anwendung ist am einfachsten zu schreiben, da man sie mit einem Werkzeug wie Delphi mit relativ wenig Aufwand zusammensetzen kann. Allerdings muß dann bei jeder Änderung auch sichergestellt werden, dass alle Anwender auch die aktuellste Version installiert bekommen.
Ein fat client muß dagegen nur geupdatet werden, wenn sich die Funktionalität der Oberfläche ändert. Änderungen in der Datenverarbeitung werden nur in der Serveranwendung durchgeführt.
Eine Web-Anwendung kann ich immer aktualisieren, ohne dass der Anwender mit Updates in Berührung kommt.
Anwendungen mit
ActiveX, bzw. Java-Applets liegen irgendwo dazwischen. Wenn die Komponenten aktualisiert werden müssen, hat man auch das Update-Problem, allerdings wird es im Browser ausgeführt.
Damit ergeben sich für den jeweiligen Einzelfall Anhaltspunkte, wie man eine Anwendung schreiben soll.
Die Programmiersprache dagegen liegt erst ganz am hinteren Ende der Entscheidungsfindung. Hier sollte man sich nach vorhandenem Know-How, evtl. bereits installierter Server-Hard- und Software usw. richten.
Ich selbst erstelle Webanwendungen mit PHP, VBScript (ASP) und Delphi.
Die PHP-Anwendungen sind mehr interaktive Webseiten. eo die Information im VOrdergrund steht und nicht die Datenbe- und verarbeitung.
Die VBScript-Programme sind für kleinere Benutzerkreise, welche aber oft Anpassungen am Programm beötigen. Das geht hier schnell - Seite in Editor laden, ändern und speichern - fertig.
Mit Delphi dagegen schreiben wir Programme, welche relativ komplex sind und die meistens wieder auf dem Server über ein Fremd-
API auf die Software von Drittanbietern zugreifen.
Ein guter Ansatz ist auf jeden Fall der Vorschlag, die Geschäftslogik in einem Web-Service zu implementieren. Dieser läuft als "Applikationsserver light" und kann seine Funktionen sowohl Webanwendungen, Java-Applets, als auch lokalen rogrammen zur Verfügung stellen.
Oft greifen wir zumindest auf diesselben Daten mit Web- und lokalen Anwendungen zu. Für Aufgaben, welche von einigen wenigen Benutzern abgewickelt werden, schreiben wir lokale Programme. Die Aufgaben für größere Anwenderkreise lösen wir dagegen mit Webanwendungen.
Um noch mal auf .NET zu kommen: Damit erhöht man die Produkivität enorm - und mit dem kommenden .NET 2.0 noch mehr. Mann kann auch in PHP sauber programmieren, doch es erfodert mehr Disziplin und Einarbeitung. Und dann sollte man auch eine gute
IDE verwenden, wie z.B. Eclipse. Auch bei PHP kann man den QUellcode für den Anwender verschlüsseln - aber das kostet eben ein wenig.
UM eine wirklich gute Produktivität bei PHP zu erreichen, muß man auch in kommerzielle Produkte investieren, ist dafür aber bei entsprechender Vorgehensweise weitgehend plattformunabhängig.
Wenn klar ist, dass man mit der Windows-DotNET-Plattform auskommen wird, fährt man da vermutlich besser. Und - man kann Teise des Quellcodes sowohl für lokale, als auch Webanwendungen verwenden.
