Jetzt möchte ich auch noch meinen Senf dazugeben. Ich stecke zwar erst in meinem ersten Webprojekt (ZK), aber das durchstöbern von verschiedenen Frameworks kenne ich nur zu gut.
bronks hat gesagt.:
m.E. gehen viele Leute da etwas verkehrt ran. Stand der Dinge ist momentan J2EE und daran wird sich jahrelang nichts ändern....sollte man sich den J2EE Patternkatalog reinziehen
Obwohl kein J2EE-Profi bin, kann ich das nicht gut heißen. Der Anteil der Lightweight-Lösungen nimmt stark zu. Selbst Java-Promoter IBM hat auch PHP als "Programmiersprache" aufgenommen.
Ich kann die schlechte Presse für J2EE zum Teil nachvollziehen:
Businessweek
Ein-Bunt-und-Klick-Tool (Lansa, aber auf DOT.NET vs. Java achten!)
mMn sollte man sich das "Monster J2EE", so gut es geht ersparen - vor allem wenn man noch nicht damit vertraut ist. Bis man sich da eingearbeitet hat, ist man mit anderen Lösungswegen dem Ziel wohl schon sehr nahe...
Es mag schon sein, dass man ab einer gewissen Größenordnung nicht darum herumkommt (z.B. wenn die Persistenzschicht auf verschiedene Datenbanken verteilt ist und man sich sicher sein muss, dass ein COMMIT nur dann geht, wenn es sicher überall geht). Wenn man Load-Balancing zwischen von mehreren Applicationservern braucht, tut's der Tomcat auch nicht mehr (laut Hilfe, kann Tomcat nur nach einfachen Regeln aufteilen - kann ja noch werden).
ABER alles darunter --> Finger weg und kleinere Brötchen backen
Bevor das hier in ein Anti-J2EE und Pro .NET Posting übergeht:
Man kommt mit .NET & Co. (lernen inklusive) sicher schneller ans Ziel als mit J2EE.
ABER: Mit MS fängt man sich ja auch allerlei Problemchen ein. Das wichtigste: Laut einer Studie (in der Computerwelt abgedruckt) ist bei den MS-Entwicklungstools mit jeder Version 50% des Codes zu warten, bei Java nur 20%.
Die Zahlen finde ich zwar ein wenig "krass", aber wer schon mal mit MS-Tools entwickelt hat, kann davon sicher ein Lied singen (z.B. geänderte Defaultwerte in der API nach Servicepack...). Manches läuft einfach aus (VB6 und ASP) und für den Nachfolger (VB.NET, ASP.NET) muss man dann doch an die Sourcen.
Hier noch meine Eindrücke zu den gesichteten Lösungen/Frameworks:
Hibernate
Hibernate wurde ja schon angesprochen. Aber es macht nicht nur das Mapping, sondern entkoppelt auch von der Datenbank. Dank eigener Abfragesprache (SQL like)muss man sich nicht mit den verschiedenen SQL-Dialekten herumschlagen(*), sondern Hibernate. Auch unterschiedliche Speicherformate für Dateninhalte (z.B. BLOB's, CLOB's..) gleicht Hibernate aus.
(*) Wenn man Direktabfrage durchschleußt, ist DB-Unabhängigkeit wieder in der Hand des Entwicklers.
Servlet
Auch wenn man keine Web-Anwendungen so schreiben sollte, ist das Verstehen der Servlet's absolute Pflicht für Java-Webentwicklung.
JSP
Mit Tag's ist die Entwicklung schon etwas erträglicher. Bei JSP sieht man erstmalig, wie einem JavaBeans Arbeit abnehmen können (gleichnamige Formularfelder können automatisch im Bean übernommen (setXxxxx) werden).
Struts
Ich habe zwar noch kein "schöne" Strutsanwendung gesehen, aber bei den angebotenen Lösungen musste ich mich wenigstens nicht fragen "Wozu brauche ich das?". Beispiel: Fehlermeldungen an die html-Seite schicken. Eine einfache Fehlermeldung (aus dem Model) auszugeben kann, bei einer MVC2-Applikation schon kompliziert werden.
--> nicht ganz schlecht, aber eine klassiche Webappl. ist nicht mein Ziel
Spring
Lösungen für Probleme die ich noch nicht habe....
Dependency Injection in einfachen Worten
Das Problem: Ich brauche ein Objekt der Klasse C. Diese ist abhängig von Klasse B und diese wiederum von Klasse A.
Die Lösung: Um aus abhängigen Klassen wieder einfache Klassen (wie POJO's) zu machen, werden die Abhängigkeiten in einer XML-Datei hinterlegt. Damit kann ich das fertige Objekt der Klasse C anfordern. Das Framework erledigt den Rest.
Aspektorientierte Programmierung stark vereinfacht
Gleichartige Arbeit (z.B. Logging, Securtycheck) = Aspekte werden ausgelagert und zu eigenen Klassen abgehandelt.
JSF & Co
Da ich eine Nachfolgeplattform für eine reine Textanwendung (IBM AS/400 alias i5 alias iSeries) kommt für mich/uns eine klassiche Weboberfläche nicht in Frage. Der Grund dafür sind zahlreiche tastaturintensive Anwendungen wie z.B. der Telefonverkauf. Bei uns fällt die Auswahl eher zwischen SWT & Swing & Ajax-Web.
ZK - Ajax without Javascript
Aufgrund der gewünschten Tastaturbedienbarkeit, schien eine Weblösung schon außer Sicht. Aber Dank AJAX können sogar Funktionstaten und STRG/ALT Kürzel in der Webapplikation abgefragt werden. Auch die mitgelieferten Widgets sind gut mit der Tastatur bedienbar.
Aber das Wichtigste: Die Entwicklung mit ZK ähnelt doch der Desktopentwicklung. D.h. ich kann einem Button eine Javaklasse/Methode zuordnen und diese Methode kann noch Änderungen an der Seite vornehmen, ohne eine neue Seite aufbauen zu müssen. Hier ist man dem Desktop-MVC schon wieder recht nahe.
ZK erfordert nicht zwingend ein weiteres Framework - ist aber mit vielen (Hibernate, Spring, Struts..) kombinierbar. Für Ausführung reicht ein Webcontainer/Tomcat.
