© sirtravelalot/Shutterstock.com
MVC 1.0 - das aktionsbasierte Web-Framework für Java EE

Endlich am Ziel!


Die MVC-1.0-Spezifikation hat eine turbulente Geschichte. Die ursprünglich für Java EE 8 geplante Spezifikation wurde Anfang 2017 von Oracle der Community übergeben und seitdem aktiv weiterentwickelt. Inzwischen steht sie kurz vor dem finalen Release. Grund genug, sich die Geschichte von MVC 1.0 und den aktuellen Stand des API einmal genauer anzuschauen.

Die Idee von aktionsbasierten Web-Frameworks ist nicht neu. Schon seit vielen Jahren scheinen besonders die beliebtesten serverbasierten Frameworks diesem Modell zu folgen. Spring MVC, Grails, Struts, Rails und Express basieren auf der einfachen, aber effektiven Idee, den Request/Response-Lebenszyklus ins Zentrum zu rücken und auf unnötige Abstraktionen zu verzichten.

Umso mehr verwunderte es, dass Java EE in diesem Bereich bisher nichts vorzuweisen hatte. Mit JavaServer Faces (JSF) bietet Java EE zwar ein mächtiges und flexibles Web-Framework, mit dem besonders formularbasierte Anwendungen sehr effektiv entwickelt werden können, jedoch ist JSF ein klassischer Vertreter der komponentenorientierten Frameworks, wie Wicket, GWT und Vaadin. An JSF ist sicherlich nichts falsch. Sowohl aktionsbasierte als auch komponentenorientierte Frameworks haben ihre Existenzberechtigung, abhängig von den individuellen Anforderungen des Projekts. Frameworks wie JSF versuchen, möglichst viele technische Details vor dem Entwickler zu verbergen und erlauben ihm, mit Hilfe vorgefertigter Komponenten viele Standardfälle sehr einfach umzusetzen. Obwohl man mit solchen Komponenten schnell zu vorzeigbaren Ergebnissen kommt, schwächeln sie oft bei der Möglichkeit, in Details einzugreifen und speziellere Anwendungsfälle umzusetzen. Im Gegensatz dazu verzichten aktionsbasierte Frameworks auf Abstraktionsschichten und rücken den HTTP-Request/Response-Lebenszyklus in den Vordergrund.

JSR 371

Die Geschichte der MVC-1.0-Spezifikation [1] beginnt mit dem Java EE Community Survey, den Oracle Ende 2015 veröffentlichte, um Feedback für die Roadmap von Java EE 8 einzuholen. Dort fand sich auch die Frage, ob sich die Community zusätzlich zu JSF ein aktionsbasiertes Web-Framework wünschte. Über 60 Prozent der knapp 4 500 Teilnehmer sprachen sich für ein solches leichtgewichtigeres Web-Framework für die nächste Java-EE-Version aus.

Kurz darauf wurde mit JSR 371 ein entsprechender Java Specification Request ins Leben gerufen. Die Expert Group nahm schnell die Arbeit auf und stand direkt zu Beginn vor einer zentralen und wegweisenden Entscheidung. Sollte MVC 1.0 als Bestandteil von Java EE auf anderen Technologien der Plattform, wie JAX-RS und CDI, aufsetzen oder stattdessen ein von Java EE unabhängiges und dadurch potenziell leichtgewichtigeres API definieren? Nach langen, intensiven Diskussionen einigte man sich auf die enge Integration in Java EE. Warum auch sollte MVC 1.0 das Rad neu erfinden, wenn Aspekte wie das Routing, das Binden von Parametern und ein mächtiges Komponentenmodell schon von JAX-RS und CDI bereitgestellt wurden?

Die große Enttäuschung kam dann zur JavaOne 2016. Nachdem Oracle die Entwicklung von Java EE 8 fast ein Jahr komplett hatte schleifen lassen, wurde auf der Konferenz die aktualisierte Roadmap für Java EE 8 veröffentlicht. Der Plan enthielt einige neue Funktionen, die aus Oracles Sicht wesentlich dafür waren, Java EE für die Cloud fit zu machen. Allerdings wurden auch einige Themen von der Roadmap gestrichen, so auch leider die MVC-1.0-Spezifikation. Die Begründung, dass Microservices meist keine Benutzeroberfläche mitbringen und MVC somit nicht mehr benötigt würde, war zwar wenig überzeugend, aber die Entscheidung war zu diesem Zeitpunkt bereits gefallen. Besonders enttäuschend ist im Nachhinein, dass Oracle kein einziges der angekündigten neuen Features in Java EE 8 umgesetzt, sondern lediglich den Gesamtumfang reduziert hat.

Trotzdem war das Interesse der Java-EE-Community an MVC 1.0 auch weiterhin sehr groß. Daher beschloss ein Teil der Expert Group, zu versuchen, MVC unabhängig von Oracle weiterzuentwickeln. Glücklicherweise stimmte Oracle der Idee zu und übertrug Anfang 2017 den Specification-Lead-Posten. Seitdem wird MVC durch die Community weiterentwickelt und steht heute kurz vor dem finalen Release.

Das MVC-Entwurfsmuster

Zugegebenermaßen ist der Name MVC für die Spezifikation nicht ganz glücklich gewählt. Es wurde mehrfach argumentiert, dass auch JSF ein MVC-Framework sei, was sicherlich nicht falsch ist. MVC hat in seinen Ursprüngen nichts mit Webanwendungen zu tun, es ist entstanden in den späten siebziger Jahren, im Kontext von Benutzeroberflächen für Smalltalk. In Bezug auf Webanwendungen wird mit dem Begriff meist die Aufteilung der Verantwortlichkeiten bei aktionsbasierten Web-Frameworks beschrieben. Abbildung 1 zeigt das typische Verarbeitungsmodell eines solchen Frameworks.

kaltepoth_mvc_1.tif_fmt1.jpgAbb. 1: Das MVC-Entwurfsmuster

Der Lebenszyklus beginnt stets mit der Anfrage eines Clients. Anhand des angefragten URL wird der Request einem Controller zugeordnet. Dieser Schritt wird auch als Controller Matching bezeichnet. Der Controller bestimmt anhand der im Request enthaltenen Informationen, was genau zu tun ist. Das kann ein Zugriff auf die Datenbank oder Ähnliches sein. Eine der wichtigsten Aufgaben des Controllers ist es, das Model zu aktualisieren. Der Begriff Model ist an dieser Stelle ein eher abstraktes Konzept. Einfach gesprochen handelt es sich beim Model um eine Datenstruktur, die später für die Darstellung verwendet wird. Im nächsten Schritt wählt der Controller eine View, die für die Darstellung verwendet wird. Diese generiert die Antwort an den Client, meist in Form eines HTML-Dokuments. Dazu greift sie auf die Daten des Models zu, das vom Controller zuvor für die View vorbereitet wurden.

Wie man si...

Neugierig geworden? Wir haben diese Angebote für dich:

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