Каков наилучший способ сохранить мои POJO в Jrabrabbit JCR?

Ответ 1

Еще одна альтернатива - полностью пропустить платформу OCM и просто использовать javax.jcr.Node как очень гибкую DAO. Основная причина, по которой существуют рамки OCM, заключается в том, что с РСУБД вам нужно сопоставить объекты с реляционной моделью. С JCR, который уже является очень объектно-ориентированным (node ~ = object), эта основная причина исчезла. Осталось то, что с помощью DAO вы можете ограничить доступ своих программистов в своем коде (включая помощь автозавершения). Но этот подход на самом деле не использует концепцию JCR, что означает отсутствие схем и гибкое программирование. Использование JCR API непосредственно в вашем коде - лучший способ следовать этой концепции.

Представьте, что вы хотите добавить новое свойство к существующему объекту node позже в течение срока действия вашего приложения - с базой OCM, которую вы также должны изменить, и убедитесь, что она по-прежнему работает правильно. При прямом доступе к узлам это просто одна точка изменения. Я знаю, это хороший способ получить проблемы с опечатками, например. имена свойств; но этот страх на самом деле не подкреплен действительностью, так как вы в большинстве случаев очень быстро заметите опечатки или несоответствующие имена при тестировании своего приложения. Хорошим решением является использование строковых констант для общих имен node или свойств, даже как часть ваших API, если вы открываете JCR API через них. Это все еще дает вам гибкость, позволяющую быстро добавлять новые свойства без необходимости применять уровни OCM.

Чтобы иметь некоторые ограничения на то, что разрешено или что является обязательным (например, "полусхема" ), вы можете использовать типы node и mixins (с JCR 2.0 вы также можете изменить тип node для существующего контента): таким образом, вы можете полностью справиться с этим уровнем на уровне хранилища и не должны заботиться о наборе текста и ограничениях внутри кода вашего приложения - кроме обнаружения исключений; -)

Но, конечно, этот выбор зависит от ваших требований и личных предпочтений.

Ответ 2

Возможно, вам стоит взглянуть на Jackrabbit OCM, который является живым и kickin. Конечно, другим способом является сериализация/десериализация POJO вручную. Для этого существует много разных вариантов. Вопрос в том, нужна ли вам схема исправления для запроса объектов в JCR. Если вы просто хотите сериализовать в XML, то XStream - очень безболезненный способ сделать это. Если вам нужна еще схема исправлений, также есть Betwixt от Apache Commons.

Ответ 3

Существует также проект JCROM http://code.google.com/p/jcrom/. Этот проект пошатнулся на пару лет, но с лета 2013 года появилось несколько новых релизов.

Ответ 4

Это зависит от ваших потребностей. Когда вы напрямую используете javax.jcr.node, это означает, что ваш код сильно связан с основным механизмом. В средних и даже некоторых небольших проектах это не очень хорошая идея. Очевидно, что вопрос будет состоять в том, как перейти от Node к вашей собственной модели домена. Проблема довольно похожа, как на переход от Jdbc ResultSet к вашей собственной модели домена. Имейте в виду, я имею в виду с технической точки зрения проблема аналогична. С функциональной точки зрения существуют огромные различия между использованием JDBC и JCR.

Другим решающим фактором является то, можете ли вы наложить структуру в свой контент JCR или нет. Некоторые домены приложений могут (но все же лучше соответствовать JCR, чем JDBC), в других доменах контент может быть очень неструктурированным по своей природе. В этом случае OCM явно переборщит. Я бы по-прежнему советовал написать свой собственный оберточный слой вокруг классов javax.jcr. *.

Ответ 5

Кроме того, https://github.com/ilikeorangutans/omf, очень гибкий объект для JCR mapper. К сожалению, он еще не поддерживает запись. Однако мы успешно используем эту инфраструктуру в большой установке CMS.