Spezifikation / Framework-APIData3.2
Jakarta Persistence
Jakarta Persistence definiert ORM mit EntityManager, Entities, JPQL, Criteria API und Persistence Context.
Einordnung
Spezifikation / Framework-API
Enterprise-Rolle
JPA ist in Enterprise-Systemen oft die zentrale Brücke zwischen Objektmodell und relationaler Datenbank.
Fachliches Verständnis
JPA ist in Enterprise-Systemen oft die zentrale Brücke zwischen Objektmodell und relationaler Datenbank. 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
- Entity, Embeddable, MappedSuperclass.
- EntityManager und Persistence Context.
- Lazy Loading und Fetch-Pläne.
- JPQL und Criteria.
- Optimistic Locking mit @Version.
Typische Einsatzfälle
- Transaktionale Fachaggregate speichern.
- Relationale Datenbanken mit Domänenmodell verbinden.
Technisches Beispiel
java
@Entity
@Table(name = "orders")
public class OrderEntity {
@Id UUID id;
@Version long version;
@Column(nullable = false) String customerNumber;
@Enumerated(EnumType.STRING) OrderStatus status;
protected OrderEntity() {}
}
@ApplicationScoped
public class JpaOrderRepository {
@PersistenceContext EntityManager em;
public Optional<OrderEntity> find(UUID id) {
return Optional.ofNullable(em.find(OrderEntity.class, id));
}
public void save(OrderEntity order) { em.persist(order); }
}
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
- N+1 Query Problem.
- Entity als API DTO.
- Unklare Transaktionsgrenzen.
- Open Session in View als Architekturkrücke.
Legacy-Modernisierung
JDBC/Stored-Procedure-lastige Systeme werden schrittweise mit Repository/DAO-Schichten und JPA-Mappings ergänzt.
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?