Другая альтернатива - полностью пропустить инфраструктуру OCM и просто использовать javax.jcr.Node как очень гибкий сам DAO. Основная причина существования OCM-фреймворков заключается в том, что в RDBMS необходимо сопоставить объекты с реляционной моделью. С JCR, который уже очень объектно-ориентирован (узел ~ = объект), эта основная причина исчезла. Осталось только то, что с помощью DAO вы можете ограничить доступ ваших программистов к своему коду (в том числе с помощью автозаполнения). Но этот подход на самом деле не использует концепцию JCR, что означает гибкое программирование без схемы . Использование JCR API непосредственно в вашем коде - лучший способ следовать этой концепции.
Представьте, что вы хотите добавить новое свойство к существующему узлу / объекту позднее в жизни вашего приложения - с помощью инфраструктуры OCM вы также должны изменить его и убедиться, что оно все еще работает должным образом. С прямым доступом к узлам это просто единственная точка изменения. Я знаю, это хороший способ получить проблемы с опечатками, например. имена свойств; но этот страх на самом деле не подкрепляется реальностью, поскольку в большинстве случаев вы очень быстро заметите опечатки или несоответствующие имена при тестировании приложения. Хорошим решением является использование строковых констант для общих имен узлов или свойств, даже в составе ваших API, если вы предоставляете им JCR API. Это по-прежнему дает вам возможность быстро добавлять новые свойства без использования слоев OCM.
Для того, чтобы иметь некоторые ограничения на то, что разрешено или что является обязательным (например, "полу-схема"), вы можете использовать типы узлов и миксины (начиная с JCR 2.0 вы также можете изменить тип узла для существующего контента): таким образом, вы можете полностью обрабатывать это на уровне хранилища и не беспокоиться о типизации и ограничениях внутри кода приложения - кроме перехвата исключений; -)
Но, конечно, этот выбор зависит от ваших требований и личных предпочтений.