© sirtravelalot/Shutterstock.com
Java Magazin
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.

Christian Kaltepoth


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, we...

Java Magazin
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.

Christian Kaltepoth


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, we...

Neugierig geworden?


    
Loading...

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