Was ist der beste Weg, um meine POJOs in Jackrabbit JCR zu speichern?

Question

In Hase ich zwei Möglichkeiten erfahren haben meine POJOs in Repository-Knoten zur Speicherung in der Jackrabbit JCR zu speichern:

1. schreibe meine eigene Schicht und
2. mit Apache Graffito

Schreiben meiner eigenen Code hat sich als zeit- und arbeitsintensiv erwiesen (er musste viele hässliche automatisierte Tests schreiben und ausführen), obwohl er ziemlich flexibel war.

Arbeiten mit Graffito ist eine Enttäuschung gewesen, weil es ein „tot“ Projekt zu sein scheint stuck in 2006

Was sind einige bessere Alternativen?

Answer 1

Eine andere Alternative ist, ein OCM-Framework komplett zu überspringen und einfach javax.jcr.Node als sehr flexibles DAO zu verwenden. Der Grund, warum OCM-Frameworks existieren, liegt darin, dass Sie mit RDBMS eine Abbildung von Objekten auf das relationale Modell benötigen. Mit JCR, die bereits sehr objektorientiert ist (Knoten ~ = Objekt), ist dieser Grund weg. Was bleibt, ist, dass Sie mit DAOs einschränken können, worauf Ihre Programmierer in ihrem Code zugreifen können (inkl. Der Hilfe der Autovervollständigung). Aber dieser Ansatz nutzt nicht wirklich das JCR-Konzept, das Schema-freie und flexible Programmierung bedeutet. Die Verwendung der JCR-API direkt in Ihrem Code ist der beste Weg, diesem Konzept zu folgen.

Stellen Sie sich vor, Sie möchten zu einem bestehenden Knoten/Objekt später im Leben Ihrer Anwendung eine neue Eigenschaft hinzufügen - mit einem OCM-Framework müssen Sie es ebenfalls ändern und sicherstellen, dass es noch ordnungsgemäß funktioniert. Mit direktem Zugang zu Knoten ist es nur ein einzelner Punkt der Veränderung. Ich weiß, das ist ein guter Weg, um Probleme mit Tippfehlern in zB zu bekommen. Eigenschaftsnamen; Aber diese Angst wird nicht wirklich von der Realität unterstützt, da Sie in den meisten Fällen Tippfehler oder nicht übereinstimmende Namen sehr schnell bemerken werden, wenn Sie Ihre Anwendung testen. Eine gute Lösung ist die Verwendung von Zeichenfolgenkonstanten für die allgemeinen Knoten- oder Eigenschaftsnamen, auch als Teil Ihrer APIs, wenn Sie die JCR-API über sie hinweg bereitstellen. Dadurch können Sie schnell neue Eigenschaften hinzufügen, ohne OCM-Layer übernehmen zu müssen.

Um Einschränkungen zu haben, was erlaubt oder was verpflichtend ist (zB. Semi-Schema) können Sie Knotentypen und Mixins verwenden (seit JCR 2.0 können Sie auch den Knotentyp für vorhandenen Inhalt ändern): also Sie kann dies komplett auf der Repository-Ebene handhaben und muss sich nicht um Eingabe und Einschränkungen in Ihrem Anwendungscode kümmern - abgesehen von den Ausnahmen ;-)

Aber natürlich hängt diese Wahl von Ihren Anforderungen und persönlichen Vorlieben ab .

Answer 2

Vielleicht möchten Sie einen Blick auf Jackrabbit OCM, die lebendig und kickin ist. Eine andere Möglichkeit ist natürlich das manuelle Serialisieren/Deserialisieren der POJOs. Dafür gibt es viele verschiedene Möglichkeiten. Die Frage ist, ob Sie ein Fix-Schema benötigen, um die Objekte in JCR abzufragen. Wenn Sie nur in XML serialisieren möchten, ist XStream eine sehr schmerzfreie Möglichkeit, dies zu tun. Wenn Sie ein mehr fixes Schema benötigen, gibt es auch Betwixt von Apache Commons.

Answer 3

Es gibt auch das JCROM-Projekt unter http://code.google.com/p/jcrom/. Dieses Projekt ist seit einigen Jahren stillgelegt, aber seit Sommer 2013 gibt es einige neue Versionen.

Answer 4

Es hängt von Ihren Bedürfnissen ab. Wenn Sie javax.jcr.node direkt verwenden, bedeutet dies, dass Ihr Code stark an den zugrunde liegenden Mechanismus gekoppelt ist. In mittleren und sogar kleineren Projekten ist dies keine gute Idee.Offensichtlich wird die Frage sein, wie man vom Knoten zu Ihrem eigenen Domänenmodell geht. Das Problem ist ziemlich ähnlich wie beim Übergang von JDBC ResultSet zu Ihrem eigenen Domänenmodell. Wohlgemerkt, ich meine aus technischer Sicht, dass das Problem ähnlich ist. Aus funktionaler Sicht gibt es große Unterschiede zwischen der Verwendung von JDBC und JCR.

Ein weiterer entscheidender Faktor ist, ob Sie Ihren JCR-Inhalt strukturieren können oder nicht. Einige Anwendungsdomänen können (aber immer noch besser mit JCR als JDBC übereinstimmen), in anderen Domänen kann der Inhalt sehr unstrukturiert sein. In diesem Fall ist OCM eindeutig übertrieben. Ich würde immer noch raten, einen eigenen Wrapper Layer um javax.jcr. * Classes zu schreiben.

Answer 5

Es gibt auch https://github.com/ilikeorangutans/omf, ein sehr flexibles Objekt für JCR Mapper. Leider hat es noch keine Schreibunterstützung. Wir verwenden dieses Framework jedoch erfolgreich in einer großen CMS-Installation.