OCM или узлы в JCR?

Question

Мы разрабатываем CMS на основе JCR/Sling/JSP/Felix/и т. Д.

То, что я нашел до сих пор, использует узлы, очень прямые и гибкие. Но моя озабоченность со временем может стать слишком сложной для поддержания и управления.

Итак, разумно ли инвестировать в использование OCM? Будет ли это просто дополнительным слоем сложности? Какая реальная польза в OCM, если таковая есть? Или нам лучше держаться за узлы?

И, наконец, является ли Jackrabbit OCM лучшим вариантом для нас, если мы хотим идти по этому пути?

спасибо.

Answer 1

В моем личном опыте я могу сказать, что это сильно зависит от вашей ситуации, если OCM является полезным инструментом для вашего проекта или нет.

Настоящая проблема при использовании OCM (в моем личном опыте) заключается в изменении определения класса, используемого в существующих сохраняемых данных (как объектов) в репозитории. Например: вы сочли необходимым изменить некоторые элементы и методы класса, чтобы они соответствовали изменениям функциональности. Под этим я подразумеваю, что определение класса объекта сохраняемых данных в репозитории больше не соответствует определению фактического класса. Когда сохраненные данные сохраняются в репозитории jcr, он обычно сохраняется в формате, который java понимает с точки зрения сериализации. Это означает, что когда что-то меняется в определении используемого класса, сохраненные данные в репозитории более не могут быть правильно интерпретированы java. Эта проблема имеет тенденцию приводить к сложному развертыванию, когда вам нужно преобразовать старые объекты сохраняемых данных в новое определение и снова сохранить их в репозитории, чтобы убедиться, что вы все еще можете использовать «старые», но все же требуемые сохраняемые данные.

Что работает (на мой взгляд), использует фреймворк, который позволяет напрямую привязывать объекты узлов и узлов к объектам Java (например, с помощью аннотаций) и наоборот (сохраняйте объект java в репозитории как JCR, где поля java-членов являются действительными свойствами узла). Таким образом вы придерживаетесь представления данных jcr (узлы со свойствами) и все еще можете сопоставить их с членами класса java.

Раньше я использовал фреймворк, подобный этому в cms под названием AEM (Adobe), хотя я должен упомянуть об этом в контексте OSGI (но принцип все еще стоит). Используемая структура в основном обеспечивает максимальную гибкость и сохраняет объект Java как узел JCR и наоборот. Поскольку он непосредственно сопоставлен с определением jcr, код изменяет класс и члены, просто изменяя аннотации, а старые сохраненные данные по-прежнему можно использовать без особых усилий.