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.
Diagramm zu Jakarta MVC

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?