© Excellent backgrounds/Shutterstock.com
Kolumne: EnterpriseTales

Java EE 8 meets MVC: ein Blick in die Kristallkugel


Für viele überraschend hat Oracle für Java EE 8 einen neuen Java Specification Request zur Ergänzung des aktuellen Web-Development-Stacks angekündigt: MVC 1.0. Obwohl bisher kaum Details zum neuen API bekannt wurden, spaltet der JSR 371 schon jetzt die Community. Grund genug, einen Blick hinter die Kulissen zu wagen.

Ist es sinnvoll, bei all den existierenden Web-MVC-Frameworks ein weiteres zu erfinden? Und wenn ja, muss es dann unbedingt in die Java-EE-Spezifikation einfließen? Schließlich gibt es doch JSF als die Lösung, wenn es um die Umsetzung von Webanwendungen im standardisierten Java-Enterprise-Umfeld geht.

Fakt ist, dass im Rahmen einer Java-EE-8-Umfrage von Oracle mehr als 60 Prozent aller Befragten der Meinung waren, dass der Standard dringend ein „Action-based“ Web-MVC-Framework benötigt. Lediglich 26 Prozent der befragten Teilnehmer waren der Meinung, dass ein solches Framework als De-facto-Standard bereits existiert. Gemeint war damit in den meisten Fällen Spring MVC.

Action- vs. Component-based

Um die aktuelle Diskussion rund um MVC 1.0 [1] besser einordnen zu können, lohnt sich ein Blick auf den wirklich guten Blog-Eintrag „Why another MVC?“ [2] von Ed Burns, seines Zeichens Co-Lead der JSF-Spezifikation. Burns beschreibt darin die wesentlichen Unterschiede zwischen „Component-based“ (JSF) und „Action-based“ (u. a. Spring MVC) Webframeworks.

Vereinfacht gesprochen abstrahiert JSF mit seinem komplexen Lifecycle von dem im Web allgegenwärtigen HTTP-Request/-Response-Modell und nimmt so dem Webentwickler eine Menge an lästigen Aufgaben ab, z. B. Request Parameter Mapping, Konvertierung, Validierung, Navigation und Rendering. UI-Komponenten, wie z. B. Eingabefelder oder Buttons, erzeugen Events, die zu einer Änderung des Modells führen. Die Kehrseite: Der Entwickler verzichtet auf einen Großteil an Freiheiten, insbesondere in Bezug auf das zu rendernde HTML. Das gilt zumindest, wenn der Life­cycle nicht explizit an die eigenen Bedürfnisse angepasst wird. Komponentenbasierte Frameworks wie JSF ergeben somit immer dann Sinn, wenn man von HTML/CSS/JS und HTTP abstrahieren und einen Satz von vordefinierten UI-Komponenten – inklusive UI-Logik – einsetzen möchte. Pixelgenaues HTML-Design mit JavaScript-Voodoo dagegen stellt bei dieser Art von Frameworks eine nicht zu unterschätzende Herausforderung dar.

Klassische „Action-based“ Frameworks dagegen gehen genau den umgekehrten Weg und stellen den HTTP-Request/-Response in den Fokus. Der eingehende Req...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang