J and I and Me
2005-10-14
 
JSF oder Struts?

Auf der Web Site des Java Magazin ist die aktuelle Umfrage: "Setzen Sie bei Ihren neuen Java-Webprojekten auf Struts oder JavaServer Faces (JSF)?" Ich finde diese Sache in so fern interessant, als das ich mich vor kurzem mit beiden Frameworks im Rahmen der Spring Integration beschäftigt habe. Ich bin natürlich vorbelastet, aber nach meinem Empfinden ist Struts ganz klar technologisch einfach veraltet. Vor allem das Paradigma, dass man seine Klasse von vorbereiteten Struts Klassen ableiten muss, ist einfach schlecht. JSF sieht hier besser aus. Dennoch verstehe ich nicht, warum JSF vor allem den Fokus auf die Unterstützung unterschiedlicher Front Ends legt, wo es doch sowieso ganz primär immer um Web Anwendungen geht. Auch der Fokus auf die Unterstützung von Web GUI Buildern löst zumindest bei nicht-trivialen Projekten nicht das zentrale Problem, nämlich das Design der Anwendung.

Eine interessante Sache ist auch die Unterstützung von Validierungen: Bei Struts muss man hier eine eigene Klasse implementieren, die von einer vorgebenen Oberklasse erbt. Bei JSF definiert man einfache Validierung an den GUI Elementen. Dies verstehe ich überhaupt nicht: Validierung ist Geschäftslogik. Zwar nicht sehr komplex, aber immer noch Geschäftslogik. Wieso soll man das direkt an die GUI Elemente hängen? Das ist ein ziemlich komisches Vorgehen.

Somit ist JSF sicher ein Fortschritt, weil man mehr mit POJOs machen kann. Aber ich persönlich halte Spring MVC eher für das zu Ende gedachte Struts (aber ich bin vielleicht auch voreingenommen). Validierungen sind hier komplett vom Web Framework unabhängig und können somit auch von Rich Clients eingesetzt werden. Und vor allem entkopellt es die Views komplett von den Controllern, so dass eine Integration mit Views wie JSP, XSLT aber auch PDF oder Excel problemlos ist und zwar ohne Änderungen an den Controllern.

Nur ist Spring MVC eben weder so früh auf dem Markt wie Struts noch wird es so gepusht wie JSF, was eben der offizielle Standard ist. Und deswegen taucht es in der Umfrage des Java Magazins auch gar nicht erst auf. Aber auch wenn man Struts oder JSF benutzt, kann man Spring immer noch sinnvoll nutzen, um die Anwendung zu strukturieren. Und die Integration ist bei beiden Optionen recht einfach. Spring zwingt einen eben nicht dazu, das Spring MVC Web Framework zu nutzen...
  13:07
Bookmark and Share
Comments:
Ihre Aussage zu den Validierungen reizt mich zum Widerspruch. "Validierung ist Geschäftslogik" ist ein wenig vereinfachend, zumal der begriff "Geschäftslogik" alles andere als präzise verwendet wird. Meint das eine technische Ecke im System (wie etwa den "Business Logic Tier" oder was man sonst für Wörter dafür hat) oder ist das eher etwas Fachliches in dem Sinne, dass "Geschäftslogik" in Informationstechnologie gegossenes Wissen über das Geschäft ist. Wenn man sich für die zweite Position entscheidet, kann es durchaus Sinn machen, auch Business-Level Validierungen in der GUI zu allokieren (das macht teilweise die Bedienung einfacher; im Kern haben wir es hier mit einer Entscheidung im User Interface Design zu tun). Dem steht natürlich das berühmte "Don't Repeat Yourself" entgegen. Gerade wenn ich zu einer Komponente mit Geschäftslogik mehrere Zugänge/Benutzerschnittstellen anbieten will, werde ich in aller Regel im Sinne einer defensiven Programmierung nochmal hinter den Benutzerschnittstellen validieren. Das würde mich allerdings nicht dazu führen, dass ich die Prüfung nicht in die GUI allokiere, sondern dass ich nach Möglichkeiten suche, die Prüfung einmal zu formulieren und von dort aus über Generatoren oder Parametrisierung die Prüfung an die richtige Stelle schaffe.

Ausserdem sind nicht alle Validierungen Geschäftslogik. Es gibt auch Prüfungen, die mit Repräsentation oder Technik zu tun haben (beispielsweise Datumseingabe nur in einem bestimmten Format, um die Programmierung der Konvertierungsroutinen zu vereinfachen). Bei Nicht-Business-Prüfungen macht es oft eine Menge Sinn, die die direkt in die GUI zu allokieren.

Bottom line wünsche ich mir von Framework-Autoren zwei Dinge :
- Die Möglichkeit, Validierungen dorthin zu packen, wo ich sie brauche
- Die Möglichkeit, Prüfungen als eine zentrale Geschäftsregeln zu beschreiben und über Build-Time- oder Laufzeitmechanismen dafür zu sorgen, dass die Prüfung zur richtigen Zeit an der richtigen Stelle aufgerufen wird.

Mit freundlichen Grüßen

Erich Pawlik
 
JSF soll ja nun eine Fortentwicklung von Struts sein. Struts hat einen Ansatz, wie Sie ihn empfehlen: Mit http://struts.apache.org/userGuide/dev_validator.html kann man die Validierungen deklarieren und entweder auf dem Server mit Java oder auf dem Client mit JavaScript machen. Mein Argument ist nun, dass nach meinem Wissensstand dies nicht etwa in JSF ausgebaut wurde, sondern dass dabei landet, dass ein Teil der Validierung in der GUI (JSP) und ein Teil im Java-Programmcode. Das ist kein Fortschritt und eine Illustration meiner These, dass JSF eben keine wirklich tolle Fortentwicklung von Struts ist, aber trotzdem am Markt erfolgreich sein wird, weil es eben ein offizieller Standard ist.

Mir ist eine zentralisierte und einfache Implementierung der Validierung, wie Spring MVC sie vorsieht lieber. Natürlich ist gerade im Hinblick auf AJAX eine reichere GUI lieber, aber man könnte auch hier argumentieren, dass Server-seitige Validierung dadurch breiter einsetzbar ist, weil die Kosten für einen Aufruf einer Server Methode sinken. Dass Validierungen mit Deklarationen und flexibler Umsetzung in GUI oder Server wünschenswert ist, sehe ich allerdings auch so.
 
Ich hatte bei meinem Kommentar eigentlich mehr die Aussage "Validierungen sind Business Logik" im Hinterkopf als die Struts versus JSF versus Sonstwas-Frage. Validierungen sind ein technischer Mechanismus, keine Business-Logik (es sei denn, man bezeichnet mit "Business Logik" einen Platz im System, was viele ja tun). Validierungen fussen (wenn Sie nicht einfach durch Technologie bedingt sind) auf Geschäftsregeln. Aus fachlicher Sicht ist die Anforderung an das System, diese Geschäftsregeln zu beachten. Wo ich die genau prüfe, ist rein eine Frage des Designs (extern oder intern).

Gruß

Erich Pawlik
 
Kommentar veröffentlichen

<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff