Spezifikation / Framework-APICore4.1

Jakarta Contexts and Dependency Injection

CDI liefert typsichere Dependency Injection, Scopes, Producer, Events, Interceptors und Decorators.

Einordnung
Spezifikation / Framework-API
Enterprise-Rolle
CDI ist das Rückgrat moderner Jakarta-Anwendungen. Es entkoppelt Objekterzeugung von Fachlogik.
Diagramm zu Jakarta Contexts and Dependency Injection

Fachliches Verständnis

CDI ist das Rückgrat moderner Jakarta-Anwendungen. Es entkoppelt Objekterzeugung von Fachlogik. 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

  • @Inject und Constructor Injection.
  • Scopes wie @ApplicationScoped, @RequestScoped, @Dependent.
  • Producer für technische Objekte.
  • Events für lose Kopplung.
  • Interceptors und Decorators für Erweiterung.

Typische Einsatzfälle

  • Fachservices ohne statische Singletons bauen.
  • Domain Events innerhalb eines Deployments verteilen.

Technisches Beispiel

java
@ApplicationScoped
public class InvoiceService {
    @Inject InvoiceRepository repository;
    @Inject Event<InvoiceCreated> events;

    @Transactional
    public InvoiceId create(CreateInvoice command) {
        Invoice invoice = Invoice.from(command);
        repository.save(invoice);
        events.fire(new InvoiceCreated(invoice.id())); // Observer Pattern
        return invoice.id();
    }
}

public void onInvoice(@Observes InvoiceCreated event) {
    System.out.println("Invoice created: " + event.id());
}
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

  • Mehrdeutige Beans ohne Qualifier.
  • State in @ApplicationScoped Beans halten.
  • CDI Events als Ersatz für persistente Integration missbrauchen.

Legacy-Modernisierung

EJB @Stateless Services lassen sich häufig als CDI @ApplicationScoped Services modellieren.

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?