MVC 1.0 oder "Warum noch ein Webframework?"

Enterprise Tales: MVC 1.0, das Aus für JSF?

Lars Röwekamp

© Software & Support Media

Dass Java EE 8 mit einem neuen, MVC-basierten Webframework (JSR 371) aufwarten wird, sollte sich mittlerweile herumgesprochen haben. Genauso wie die Tatsache, dass nicht wenige Mitglieder der Java-Community den Sinn eines weiteren Webframeworks innerhalb des Enterprise-Java-Standards in Frage stellen. Zum einen bekommt der bisherige Platzhirsch JSF Konkurrenz aus den eigenen Reihen. Zum anderen gibt es bereits MVC-Alternativen außerhalb des Standards. Muss das neue Framework also wirklich sein?

Während JSF versucht, weitestgehend von HTTP-Request/-Response zu abstrahieren und Standardaufgaben, wie Controller-/Navigation-/State-Handling, Event Dispatching und HTML-Authoring zu automatisieren, bietet MVC 1.0 eine deutlich feingranularere MCV-Fassade, welche einen Großteil der eben genannten Aufgaben dem Entwickler und Page-Autoren überlässt. Abgesehen von einfachen Templatemechanismen bietet MVC – anders als JSF – somit auch kein Konzept für wiederverwendbare Komponenten an. Im Gegenzug dazu ermöglicht MVC 1.0 einen deutlich direkteren Einfluss auf die Request-/Response-Verarbeitung und damit verbunden auch auf die HTML-Generierung. Hier setzt JSF auf Standard- und Custom-Komponenten, wo hingegen MVC 1.0 Plain HTML in Kombination mit Template Engines nutzen wird. Ein Vorteil, der sich insbesondere dann positiv auswirken dürfte, wenn die Webanwendung auf Seiten des Clients zusätzlich mit HTML-, CSS- oder JavaScript-Frameworks arbeitet.

Friedliches Miteinander

Keine Angst, ich werde an dieser Stelle bewusst auf einen Vergleich der beiden Webframeworkvarianten „Action-based“ und „Component-based“ verzichten. Dies haben bereits Ed Burns, Reza Raham und Joshua Wilson in ihren Blog-Beiträgen „Why another MVC“, „Why another MVC Framework in Java EE 8?“ und „Java MVC 1.0“ zur Genüge getan.

Diese zeigen, dass beide Varianten unterschiedliche Ziele verfolgen und somit auch unterschiedliche Zielgruppen ansprechen (sollen). Das in der Java-Enterprise-Community tatsächlich ein Bedarf für beide Facetten besteht, lässt sich interessanterweise an der Evolution von JSF ablesen. Mit Erweiterungen wie View Parameter, PreRenderView Event oder View Action haben sich in den letzten Versionen – insbesondere ab JSF 2.0 – mehr und mehr Features eingeschlichen, die eigentlich eher in Richtung Action-based MCV-Framework zielen. Eine Alternative zu MVC 1.0 wäre es somit gewesen, JSF weiter künstlich in Richtung Action-based zu drängen und so eine Art Hybridframework zu erzeugen; eine Lösung, mit der am Ende wahrscheinlich keiner wirklich zufrieden gewesen wäre.

Vielen Entwicklern wird darüber hinaus sicherlich entgegen kommen, dass bei der Spezifikation von MVC 1.0 von Anfang an die Unterstützung unterschiedlichster Template Engines mit eingeplant wird. Die Referenzimplementierung Ozark zum Beispiel wird neben den von der Spezifikation geforderten View Engines für JSP und Facelets auch Pendants für FreeMarker, Velocity, Thymeleaf, Mustache und Handlebars zur Verfügung stellen.

REST als Basis

Ebenfalls interessant ist, dass MVC 1.0 aus technologischer Sicht auf JAX-RS aufsetzt und somit jeder Controller gleichzeitig auch eine JAX-RS Ressource darstellt. Dieser Ansatz bietet sich – rein technologisch betrachtet – an, da JAX-RS sehr dicht am HTTP-Request/-Response ansetzt und so für MVC 1.0 u. a. die Matching- und Binding-Layer von JAX-RS wieder verwendet werden können. Gleichzeitig kann die REST-Ressource für die parallele „Belieferung“ unterschiedlichster Channels verwendet werden. Ob dieser Ansatz auch strategisch sinnvoll ist oder am Ende den einen oder anderen Entwickler, der keine Multi-Channel-Anwendung im Fokus hat, eher abschreckt, bleibt abzuwarten.

Fazit

In Summe scheint es durchaus sinnvoll zu sein, das „Webportfolio“ des Java-EE-Standards um ein Action-based MVC-Framework zu erweitern. Alternativ hätte man das Component-based JSF-Framework Schritt für Schritt weiter verwässern müssen, um so auch den Anforderungen derjenigen Entwickler im Java-EE-Umfeld gerecht zu werden, die eigentlich eher Action-based programmieren wollen.

MVC 1.0 wird JSF nicht ersetzen, sondern vielmehr einen zweiten, alternativen Ansatz im Webumfeld bieten. Je nach „Gusto“ bzw. nach Kontext der eigenen Webanwendung lässt sich so der jeweils passende Ansatz wählen, ohne dabei auf ein proprietäres Framework zurückgreifen zu müssen. Ob sich MVC 1.0 am Ende tatsächlich gegen den einen oder anderen De-facto-Standard – und hier denke ich insbesondere an Spring MVC – etablieren wird, bleibt abzuwarten. Hier spielt sicherlich auch eine Rolle, wie gut das neue Framework in den restlichen Java-EE-Stack integriert werden wird. In diesem Sinne: Stay tuned …

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Kommentare
  1. Rüdiger Möller2017-08-30 01:29:32

    Das klassische Server Side Rendering ist so gut wie tot. Die Musik spielt bei den Client Side JavaScript Frameworks, und nur hier gibt es Innovation, qualitativ hochwertige Open Source Komponenten etc. .

    Beispiele (react.js basierte UI Libs):
    https://react.semantic-ui.com/introduction
    http://www.material-ui.com/#/components/app-bar
    https://react-bootstrap.github.io/components.html

    Im Focus von Jee sollte eine Integration mit diesen Technologien stehen. Also JavaScript-Interopartion, JavaScript Transpilation, Bundling + Minification.

    wie z.B. hier https://github.com/RuedigerMoeller/InstrinsicReactJSX

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.