Spezifikation / Framework-APIData1.0
Jakarta Data
Jakarta Data standardisiert Repository-orientierten Datenzugriff mit BasicRepository, CrudRepository, Query Methods und Paging.
Einordnung
Spezifikation / Framework-API
Enterprise-Rolle
Es bringt ein Spring-Data-ähnliches Repository-Denkmodell in den Jakarta-Standard, ohne an eine konkrete Implementierung gebunden zu sein.
Fachliches Verständnis
Es bringt ein Spring-Data-ähnliches Repository-Denkmodell in den Jakarta-Standard, ohne an eine konkrete Implementierung gebunden zu sein. 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
- Repository Pattern als Standard-API.
- Abgeleitete Query-Methoden.
- Pagination und Cursor/Offset-Modelle.
- Trennung von Modell und Repository-Vertrag.
Typische Einsatzfälle
- CRUD-lastige Fachservices schneller bauen.
- Portablere Repository-Abstraktion verwenden.
Technisches Beispiel
java
@Repository
public interface OrderRepository extends BasicRepository<Order, UUID> {
List<Order> findByCustomerNumber(String customerNumber);
Page<Order> findByStatus(OrderStatus status, PageRequest page);
}
@ApplicationScoped
public class OrderQueryService {
@Inject OrderRepository repository;
public Page<Order> openOrders(int page) {
return repository.findByStatus(OrderStatus.OPEN, PageRequest.ofPage(page).size(50));
}
}
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
- Repository als Ort für Fachlogik.
- Komplexe Queries in Methodennamen pressen.
- Anbieterfähigkeiten mit Standard verwechseln.
Legacy-Modernisierung
DAO-Schichten können in Jakarta-Data-Repositories überführt werden, Fachlogik bleibt im Application Service.
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?