Jpa2 -> jaxb???

[Landei]

Hallo Leute,

nachdem ich in meinem Projekt die Persistenzschicht mit JPA2 (stand-alone) so einigermaßen im Griff hatte, ist es den höheren Mächten eingefallen, die Architektur komplett umzukrempeln und auf XML umzusteigen. Ich kann gar nicht soviel essen, wie ich k%&$&n möchte. Absoluter Irrsinn...

Ich habe noch nie mit JAXB gearbeitet, aber die Grundlagen sind so einigermaßen klar. Aber es ist natürlich ein Unterschied, ob ich mal eben ein HelloWorld als XML-File schreiben will, oder ein komplettes Modell mit M:N-Beziehungen, Embedded Krempel und Kringelchen und Schleifchen abzubilden. Habt ihr vielleicht ein paar Tipps für mich auf Lager? Ich meine, außer zu kündigen?

 

[maki]

Ich meine, außer zu kündigen?

YMMD

k.A. ob das hilft, aber wenn die öfters solche seltsamen Ideen haben sollten, lohnt es sich vielleciht irgendwann auf JDO umzusteigen, das ist nämlich - anders als JPA - nicht auf RDBMS beschränkt.

 

[Landei]

Interessante Idee, schau ich mir mal an.

 

[Ebenius]

Bevor die Trivial"lösungen" ganz vergessen werden: Sicher, dass sich das Problem nicht wegdiskutieren/aussitzen/vergessen/delegieren lässt? Vielleicht wartest Du einfach zwei Wochen, bis die Anforderungen sich wieder zum Besseren geändert haben werden?

Mit der knappen Beschreibung kann man natürlich nur sehr begrenzt erahnen, wie das neue Persistenzkonzept ausschauen soll…

Ebenius

 

[Orolhawion]

[...] komplettes Modell mit M:N-Beziehungen [...]

auf jeden fall einen blick auf folgende annotationen werfen:

@XmlID
@XmlIDREF
@XmlElement
@XmlElements

damit sollten jedenfalls die beziehungen schonmal kein problem darstellen.

 

[Wildcard]

Nimm EMF statt JaxB. Bei EMF ist es egal ob du binär, textuell, XMI, XML oder in eine Datenbank über JPA serialisierst.
Für JPA im speziellen gibt es EclipseLink und EMF Teneo, XML wird sowieso out-of-the-box unterstützt.

 

[Landei]

Danke für die Tipps! Aussitzen ist leider nicht, und ändern wird sich das auch nicht, denn der Grund für den Schwenk waren Sicherheitsbedenken (sprich: Paranoia).

 

[Wildcard]

Falls EMF für dich in Betracht kommt, sollte die Umstellung eigentlich recht einfach sein. Falls für deine Modellklassen schon Interfaces exisitieren kannst du einfach die Interfaces mit EMF Annotations versehen und daraus ein Ecore erzeugen lassen. Für den Rest der Anwendung sollte dann alles beim Alten bleiben. Wenn du keine Interfaces hast lässt sich das mit Extract Interface Refactoring ziemlich automatisiert erledigen.
Sobald du das Ecore hast kannst du daraus Implementierungen generieren die als Hybrid funktionieren sollten, also aus der DB geladen werden können und anschließend als XML gespeichert werden können.
Wenn du kein Hybridmodell brauchst (weil du zB keine Bestandsdaten migrieren musst), ist es wohl einfacher direkt ein Ecore anzulegen, oder aus einem XSD zu importieren.
Egal wie hast du später den Vorteil das es dich später nur ein müdes Lächeln kostet wenn statt XML doch wieder eine DB verwendet werden soll.

 

[Landei]

Die Frage, die sich jetzt nach einiger Beschäftigung mit EMF stellt ist, wie XMI ins Bild passt. Ist es möglich, ausgehend von einem ECore ein bestimmtes XML-Mapping zu generieren (so dass eine Reihe von XML-Dateien wie eine Datenbank verwendet werden kann), oder bin an XMI gebunden?

Und sehen ich es richtig, dass ich für meinen Client eine Art "EMF-Runtime" mitliefern muss?

 

[Wildcard]

Die Frage, die sich jetzt nach einiger Beschäftigung mit EMF stellt ist, wie XMI ins Bild passt. Ist es möglich, ausgehend von einem ECore ein bestimmtes XML-Mapping zu generieren (so dass eine Reihe von XML-Dateien wie eine Datenbank verwendet werden kann), oder bin an XMI gebunden?

XMI ist nur eine Serialisierungsvariante. Out-of-the-box unterstützt EMF XMI, XML, Binär, textuell und relational (zB über JPA). Wenn das nicht reicht kann man natürlich auch eigene Serialisierungsmechanismen bauen. Das schöne ist, für dein Modell ist es völlig unerheblich wie es gespeichert und geladen wird.
Um EMF Modelle in ein ganz bestimmtes XML Format zu speichern gibt es 2 Wege. Entweder Schema First, also ein XML Schema schreiben und von EMF daraus ein Modell bauen lassen, oder erst das Modell anlegen und dann annotieren um das XML Format festzulegen.

Und sehen ich es richtig, dass ich für meinen Client eine Art "EMF-Runtime" mitliefern muss?

EMF hat eine Runtime (ein jar, ein wohl so um die 200kb) die normalerweise benötigt wird. Das ist bei Jaxb auch nicht anders, nur ist Jaxb mittlerweile Teil der JRE.
Die Runtime bringt IMO enorme Vorteile da dadurch EMF Modelle bei wenig Code sehr Featurereich sind (Listener Schnittstellen, EOpposites, erweiterte Collections, EMF Reflections usw.), aber wenn man all das nicht haben möchte und absolut kein jar einbinden will der kann mit EMF Texo auch Java Pojos generieren die keine Abhängigkeit zu EMF haben (man verliert natürlich viele coole Features).