Spezifikation / FrameworkServer UI4.1

Jakarta Faces

Jakarta Faces ist ein komponentenbasiertes serverseitiges UI-Framework für Webanwendungen.

Einordnung
Spezifikation / Framework
Enterprise-Rolle
Faces ist in vielen Enterprise-Portalen vorhanden und muss für Modernisierung verstanden werden, auch wenn neue UIs oft SPA/REST nutzen.
Diagramm zu Jakarta Faces

Fachliches Verständnis

Faces ist in vielen Enterprise-Portalen vorhanden und muss für Modernisierung verstanden werden, auch wenn neue UIs oft SPA/REST nutzen. 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

  • Component Tree.
  • Managed/CDI Backing Beans.
  • Navigation und Lifecycle.
  • Validatoren und Converter.

Typische Einsatzfälle

  • Bestehende JSF/Faces-Anwendungen pflegen.
  • Formularreiche interne Enterprise-UIs.

Technisches Beispiel

java
@Named
@ViewScoped
public class OrderView implements Serializable {
    @Inject OrderQueryService query;
    private List<OrderDto> orders;

    @PostConstruct
    void init() { orders = query.openOrders(); }

    public List<OrderDto> getOrders() { return orders; }
}
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

  • Businesslogik im Backing Bean.
  • View Scope falsch im Cluster.
  • Komplexer Lifecycle wird ignoriert.

Legacy-Modernisierung

JSF Managed Beans werden auf CDI Beans migriert; Fachlogik wandert in Application Services.

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?