Der letzte Post zu dem bekannten Problem (XsdToClass) beschreibt eine Lösung, die die Transformation der Schema-Datei in eine Konfigurationsdatei (persistence.xml) für das Persistenzframework (JPA). Dieser Ansatz hat durchaus Vorteile:
- Man bleibt beim Contract-First-Prinzip.
- Bei Änderungen, muss lediglich das Schema und die Transformationsdatei (XSLT) angepasst werden.
Dem stehen allerdings auch einige Nachteile gegenüber:
- Die JPA-Konfiguration in einer XML-Datei ist unbequem und schlechter lesbar, als die Annotierung in den Klassen.
- Die Konfiguration müsste in dem Schema mit einem zusätzlichen Namespace vorgenommen werden. Es entsteht zusätzlich ein hoher Aufwand für die vollständige und korrekte Umsetzung der JPA-Konfiguration in diesem Namespace.
Schluss endlich bedeutet dies, dass ich einen weiteren Ansatz gefunden habe, der einfacher umzusetzen ist als die Variente mit der Tranformation mit XSLT. Darum nehme ich von diesem Ansatz vorerst Abstand.
Mapping von Objekten verschiedener Schichten...
... heißt mein neuer Ansatz
die folgende Grafik zeigt den groben Ablauf des Mappings
Die Modelklassen werden nach wie vor per JAXB aus einem Schema generiert. Die generierten Klassen stellen das Domainmodel dar und werden in der Logikschicht verwendet. Soll ein Objekt der Logikschicht persistiert werden, wird dieses auf ein äquivalentes JPA-Objekt gemappt. Dieses kann durch JPA gehandhabt werden. Ebenso muss in umgekehrter Richtung ein Mapping von JPA-Entities auf das Domain-Model stattfinden.
Vorteilhaft an diesem Ansatz ist:
- Eine Trennung von Schichten und die lose Kopplung werden unterstützt.
- Das Mapping ist beliebig erweiterbar.
Der Nachteil an dieser Verfahrensweise ist jedoch:
- Wenn das Model im Schema geändert wird, muss die entsprechende JPA-Entity sowie das Mapping per Hand ergänzt werden
Keine Kommentare:
Kommentar veröffentlichen