Spezifikation / FrameworkWeb MVC3.0
Jakarta MVC
Jakarta MVC standardisiert action-basiertes serverseitiges MVC auf Basis von Jakarta REST.
Einordnung
Spezifikation / Framework
Enterprise-Rolle
Es ist eine Alternative zu komponentenbasierten UIs, wenn serverseitiges MVC gewünscht ist.
Fachliches Verständnis
Es ist eine Alternative zu komponentenbasierten UIs, wenn serverseitiges MVC gewünscht ist. In der Praxis ist wichtig, die Spezifikation nicht mit der konkreten Runtime zu verwechseln. Der Standard beschreibt die portablen APIs, die Implementierung entscheidet über Konfiguration, Performance, Betrieb und Support.
Kernkonzepte
- Controller als Ressource.
- Models und Views.
- Integration mit CDI und Validation.
Typische Einsatzfälle
- Klassische serverseitige Webanwendungen.
- Einfachere Migration von Action-basierten Frameworks.
Technisches Beispiel
java
@Controller
@Path("/orders")
public class OrderPageController {
@Inject Models models;
@Inject OrderQueryService query;
@GET
public String orders() {
models.put("orders", query.openOrders());
return "orders.jsp";
}
}
Architekturregel: Jakarta APIs gehören an Systemgrenzen und Infrastrukturpunkte. Fachentscheidungen bleiben in Application Services und Domain-Modellen testbar und möglichst unabhängig vom Container.
Enterprise-Fallen
- Mit Faces-Lifecycle verwechseln.
- Views mit Fachlogik überladen.
Legacy-Modernisierung
Struts/Action-MVC-Systeme können konzeptionell einfacher auf Jakarta MVC als auf Faces migriert werden.
Vertiefung: Review-Fragen für Senior-Entwickler
- Welche Spezifikation ist hier wirklich nötig?
- Welche Runtime-Funktion wird genutzt und ist sie portabel?
- Wo liegt die Transaktionsgrenze?
- Sind API-Verträge, DTOs und Domain-Modelle getrennt?
- Ist der Code ohne Application Server testbar?