Hallo zusammen,
ist jetzt zwar schon ein paar Tage her, allerdings möchte ich kurz auf ein paar Fehlinformationen zu JSF eingehen.
deamon hat gesagt.:
Hallo Fats,
JSF ist ein Framework, das Oberflächenkomponenten für Webanwendungen bereitstellt. Optimiert wurde es für Werkzeugeinsatz, wofür aus meiner Sicht nicht tragbare Kompromisse eingegangen wurden. JSF bringt auch noch etwas für die Valdidierung und die Ablaufsteuerung (Controller) mit. Die Nachteile sind, dass ohne JavaScript praktisch gar nichts geht, dass man im URL nicht unbedingt sieht, wo man gerade ist, was auch bedeutet, dass Suchmaschinen kaum eine Chance haben und auch Lesezeichen nicht unbedingt gesetzt werden können. Die Validierung von Eingabedaten gehört aus meiner Sicht auch nicht in die Präsentationsschicht. [..] Die Performance ist auch umstritten.
ps hat gesagt.:
Nun, zum einen ist das komponentenbasierte Modell wahnsinnig ressourcenfressend. Es muss sich stets den Zustand der Komponenten merken - das kostet Speicher. Im Java Magazin war mal ein schöner Artikel darüber.. Struts war wenn ich mich richtig erinnere fast viermal schneller als JSF.
Ich weiß nicht wie es mittlerweile mit der Link Problematik aussieht - als ich mit JSF gespielt habe musste man ziemlich üble Hacks anwenden nur um die Seite suchmaschinenfreundlich zu bekommen. [..]
Meine Erfahrung ist das man in einem Internetportal früher oder später den einen oder anderen Webservice aufsetzen möchte, einen RSS Feed, evtl. einen Bereich für mobile Endgeräte. Ein komponentenbasiertes Modell unterstützt mich an dieser Stelle überhaupt nicht.
Ich fasse nochmal die zu Felde getragenen Kritikpunkte:
1.) Validierung/Konvertierung haben nichts in der Präsentationsschicht zu suchen.
Diese Aussage stimmt in den meisten Fällen, allerdings ist es in JSF kein muss, diese Möglichkeiten zu nutzen. Man kann die Validierung auch in der Geschäftslogik durchführen und dann entsprechend programmatisch Fehlerhinweise erstellen. Bei der Anzeige dieser Fehlermeldungen werden wir jedoch in beiden Fällen (sowohl über JSF-eigene Validatoren als auch beim programmatischen Ansatz) von JSF unterstützt (man kann weiterhin h:message nutzen).
2.) Ohne JavaScript geht gar nichts.
Diese Aussage ist schlicht und ergreifend falsch. Benutzt man die JSF-RI oder das Pendant Apache MyFaces, kommt man komplett ohne JavaScript aus. Lediglich wenn man sich ajaxifizierte Zusatzkomponenten ins Boot holt (Oracle ADF Faces, JBoss RichFaces, a4j, IceFaces etc.), wird Output erzeugt, der mit JavaScript angereichert ist (ist aber bei jedem anderen Webframework der Welt auch so, will ich ajaxifizierte Controls haben, benötige ich JavaScript). Den Vorteil, den ich hier sehe ist der, dass ich mit JavaScript nicht in Berührung komme und schon fertige Komponenten vorgelegt bekomme, während ich bei Controller-basierten Frameworks a la Struts & Co. mir meine Ajaxfunktionalität selbst zusammenschustern muss. Für mich, der mit JavaScript wenig zu tun haben will, ein klarer Punkt zugunsten der Komponentenframeworks.
3.) Man sieht die URL nicht (richtig) bzw. kann keine Parameter anhängen.
Grundsätzlich ist diese Aussage richtig, da man meistens die vermeintliche Seite, von der man kommt, angezeigt bekommt. Dies kann man umgehen, indem man in den Navigationsregeln <redirect /> verwendet (gibt einige Besonderheiten, die man bei der Verwendung von redirect beachten muss, aber das darf jeder selbst nachschlagen). Die Problematik mit den Parametern stimmt und ist deshalb auch in der Spezifikation zu JSF 2.0 (JSR 314) adressiert. Was vermutlich mit suchmaschinenfreundlich gemeint ist, ist der Umstand dass JSF-Anwendungen oftmals aufgrund der fehlenden Parameter nicht "bookmarkable" waren und man daher nicht mitten in eine JSF-Anwendung einsteigen konnte. Wie gesagt, mit JSF wird hoffentlich alles besser. ^^
4.) Speicherhunger von Performance von JSF
Es stimmt, dass durch die höhere Abstraktion JSF langsamer ist als z. B. JSP oder Frameworks, die auf einer niedrigeren Abstraktionsschicht als JSF operieren. Die Benchmarks, die ich kenne (u. a. auch aus dem JavaMagazin, aber auch von diversen Websites) besagten bisher aber alle einen Geschwindigkeitsnachteil von JSF, der sich im Millisekundenbereich bewegte (
http://it-republik.de/jaxenter/artikel/JSF-und-Struts-auf-dem-Leistungspruefstand-1327.html dürfte vermutlich der Artikel sein, der gemeint war). Ob dieser Geschwindigkeitsunterschied wirklich erfolgskritisch ist, muss von Situation zu Situation neu bewertet werden und kann nicht pauschal beantwortet werden. Dazu muss man sagen, dass heutzutage für viele Anwendungen die Performanz (die sich meist im Millisekundenbereich abspielt) eher sekundär ist, während Entwicklungsgeschwindigkeit und Wartbar- bzw. Erweiterbarkeit wesentlich wichtigere Erfolgsfaktoren für ein Projekt darstellen. Ähnlich verhält es sich mit dem Ressourcenhunger von JSF, für den man sich weniger Verwaltungsaufwand erkauft (wobei auch hier optimiert werden kann, wenn nicht alles in Beans aus dem Session- oder Application Scope abgelegt wird - hier wird übrigens mit JSF 2.0 der aus Spring bekannte Dialog Scope eingeführt, dürfte die Notwendigkeit für den Session Scope drastisch reduzieren). Jedoch dürfte dieser bei wenig frequentierten Websites kaum ins Gewicht fallen (zumal heute die Webserver eh schon einiges an Leistung und Speicher vorweisen können), während stark frequentierte Websites i. d. R. sowieso einiges an Hardware hintendran stehen haben (müssen), um Peaks zu überstehen. Ob auch dieser vermeintliche Nachteil sich als erfolgskritsich oder erfolgsfördernd herausstellen wird, muss wiederum von Situation zu Situation individuell bewertet werden.
5.) Ein komponentenbasiertes Modell bietet keine Unterstützung für weitere Dienste (z. B. WebServices).
Wie bereits von einem meiner Vorredner (eigentlich -schreiber ^^) angeführt, ist es auch gar nicht die Aufgabe eines Komponentenframeworks, Unterstützung für z. B. WebServices anzubieten. Ein gutes Softwaredesign zeichnet sich dadurch aus, dass eine strikte Trennung zwischen Geschäfts- und Präsentationslogik eingehalten wird. Zusätzliche Dienste wie bspw. WS setzen dabei bei der Geschäftslogik an und haben in der Präsentationsschicht nichts zu suchen (andernfalls nimmt man eine feste Verdrahtung mit der GUI in Kauf, was erfahrungsgemäß im Laufe eines Projektes zu erheblichen Mehraufwänden bei Entwicklung und Wartung führt). Ansonsten kann JSF als servletbasiertes Webframework in dieser Hinsicht nicht mehr oder weniger als andere servletbasierte Webanwendungen, egal ob diese nun controller- oder komponentenbasiert sind.
Sollten sich Fehler in meiner Darstellung eingeschlichen haben, wäre es nett, wenn ihr mir nen kleinen Tip geben könnt - man lernt ja schließlich gerne dazu
Ansonsten waren das jetzt 5 Kritikpunkte, zu denen ich kurz meine Sicht der Dinge darstellen wollte. Welches Framework man präferiert, muss jeder entsprechend der jeweiligen Ausgangssituation selbst entscheiden. Nur pauschal ein Framework als die Wunderwaffe vorzutragen (was meiner Meinung nach in diesem Forum viel zu oft geschieht), halte ich für wenig zielführend. Dafür ist die Ausgangslage einfach viel zu oft viel zu unterschiedlich.
So und jetzt seid ihr dran
PS: Noch kurz zum Thema JSF. Ich persönlich erwarte von JSF 2.0 recht viel und bin sehr gespannt, ob es die auf der Spec-Seite angekündigten Veränderungen wirklich so realisieren wird, wie ich mir das erhoffe.
