Отсоединение узла jcr: использование свойств JcrNode вне области сеанса (например, некоторый тип DTO)

Question

В настоящее время делаю тестовое приложение с JCR (Modeshape).

• Абстрагированный поток выглядит следующим образом: session.open, хранилище выбирает на или более узлов, связанных с запросом, session.close.

• Полученные узлы содержат свойства и т. Д., Которые мне нужно представить представлению.В настоящее время у меня есть наивная настройка, позволяющая представлению получать свойства непосредственно из jcrNode.Однако это выдает ошибку вроде: «Сессия с идентификатором« e2881d98-56fd-4a57-9cce-1a7d087a11e8 »была закрыта», что имеет смысл.

Я полагаю, что общий подход (пожалуйста, исправьте, если не так) будет заключаться в создании некоторого вида nodeDTO, который заполняется jcrNode, когда сеанс еще активен.Представление тогда свободно использовать nodeDTO, как ему хочется.

Теперь идеальная структура для такого nodeDTO будет имитировать структуру jcrNode 1-к-1, так почему бы не использовать jcrNode в качестве самого DTO?Это будет достигнуто с помощью чего-то похожего на спящий режим.Я понимаю, что jcrNode (с его дочерними элементами) может содержать много данных, поэтому, вероятно, должны быть некоторые параметры для определения глубины отсоединения и т. Д.

Другой подход заключается в том, чтобы иметь нечто вроде openSessionInView-pattern, хотя это будет специфично для mvc-framework.

Итак, я вижу несколько подходов к этому, сначала лучший подход (imo):

1. функция отсоединения / подключения для jcrNodes
2. хорошая библиотека вспомогательных классов для созданияDTO
3. openSessionInView

Любые комментарии к подходу "передовой опыт" и т. д. очень ценятся.

Answer 1

К сожалению, спецификация JCR 2.0 не определяет способ отсоединения узлов от сеанса, поэтому этот вид функциональности будет зависеть от реализации.

Вместо метода JCR, единственный метод, который не зависит от реализации JCR, - это копировать свойства и дочерние ссылки в очень простую структуру вашего собственного создания.Да, эта структура на высоком уровне очень похожа на узел JCR, но для этого не нужно иметь 90% методов, определенных в Node: простую карту свойств (по имени) и список (илиупорядоченная карта) дочерних узлов.И благодаря этому ваш код будет отвечать за копирование интересующих вас узлов и подграфов, поэтому вы сможете определить семантику в соответствии с вашими потребностями.

Однако, как руководитель проекта для ModeShape, я делаюсогласитесь, что отсоединение узлов JCR кажется хорошей функцией, и поэтому я зарегистрировал это как запрос расширения в проекте ModeShape.Есть много деталей, которые нужно проработать с точки зрения правильной семантики (особенно в отношении дочерних или дочерних узлов), поэтому я бы пригласил вас посмотреть этот запрос и принять участие в обсуждении по этому вопросу.

Answer 2

Я разрабатывал веб-приложение JBoss Seam поверх Modeshape-in-JBoss. Сначала я тоже использовал подход DTO, но отказался от этого. Вместо этого было проще сохранить сеанс JCR открытым, либо для сеанса разговора, либо для всего сеанса сервлета.

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

Я все еще на начальном этапе разработки, а не производства, и поэтому не могу утверждать, что это "лучшая практика". Однако до сих пор оба подхода кажутся жизнеспособными, и у меня не было с ними проблем.

Для начала у меня есть компонент Менеджер шва в области приложения (с помощью @Unwrap), который создает JCR-репозиторий (с помощью ServiceLoader), который используется для login ().

Тогда для сессии:

1. Сеанс JCR в области разговора: я создал компонент менеджера шва в области преобразования, который помещает сеанс JCR в область диалога. Компонент Seam выполняет repository.login () при создании и session.logout (), когда компонент уничтожается в конце диалога. По сути, это тот же подход, что и JPA EntityManager в области разговора, который обычно используется в приложении Seam.

2. Сеанс JCR в области сеанса: То же, что и выше, за исключением области сеанса шва (сервлета). Это, очевидно, приводит к тому, что сеанс JCR будет открыт в течение гораздо более длительного времени (потенциально часов). Я не знаю, есть ли с этим питфалы, но пока это кажется более естественным подходом.

В обоих случаях код приложения будет выполнять session.save () после выполнения любых обновлений.

Тем не менее, я согласен с тем, что какой-нибудь бессессионный API утилиты DTO был бы очень полезен. Это становится очевидным, если вы предоставляете клиенту функциональность JCR с помощью EJB. Поскольку EJB может передавать только сериализуемые объекты данных, узлы JCR, а также свойства и значения не могут передаваться напрямую. Я столкнулся с этой ситуацией при разработке приложения Eclipse RCP (дополнения к веб-приложению), которому необходим доступ к тому же репозиторию Modeshape, работающему в JBoss. В итоге я сделал нечто очень похожее на то, что рекомендовал Рэндалл: разработал простые сериализуемые объекты NodeDTO и PropertyDTO, а затем получил несколько служебных методов для их создания из узлов и свойств JCR. Если бы Modeshape или JCR могли бы предоставить эти утилиты для помощи клиент-серверному доступу к хранилищу, это было бы здорово!