JPA-код, который поддерживает использование без учета состояния и состояния - PullRequest
1 голос
/ 01 ноября 2019

У меня есть два приложения, которые совместно используют базу данных. Одно приложение, которое обрабатывает сообщения из очереди, а другое имеет экраны JSF, которые поддерживают те же функции (плюс многие другие), которые использует очередь. В коде JPA существует значительное совпадение, так что я хочу создать по одному многократно используемому модулю для обоих приложений (так же, как и при внесении изменений в запрос JPA, я должен применить его к обоим приложениям).

Теперь у нас есть идентификатор пользователя, прикрепленный к каждой строке в базе данных. Когда строка создается в ответ на сообщение очереди, идентификатор пользователя является статическим «SYSTEM_X_ID» (например). Но когда строка была создана пользователем через экран JSF, это будет идентификатор пользователя в сеансе.

Вот в чем моя проблема - версия приложения не имеет сессии. Объект сеанса вводится. Итак, как я могу написать повторно используемый код базы данных, чтобы проверить наличие внедренного объекта сеанса, который будет внедрен в приложение JSF, но не в приложение очереди? Возможно ли это вообще?

Одна из идей, которые у меня были до сих пор, состоит в том, чтобы изменить класс BaseDao так, чтобы все другие классы Дао расширялись таким образом, чтобы в версии очереди он назначался статически без ссылки на объект сеанса и вВерсия JSF внедряет объект сеанса и использует в нем идентификатор пользователя. Я предпочел бы не делать этого, хотя - отсюда мой вопрос.

Заранее спасибо.

1 Ответ

0 голосов
/ 01 ноября 2019

(при условии, что под сессией вы подразумеваете HttpSession)

Зависимости должны идти только в одну сторону. Зависимость уровня доступа к данным от чего-то определенного для веб-слоя кажется плохой вещью. И это плохо, потому что ограничивает способ повторного использования, которого вы пытаетесь достичь.

На HttpSession следует ссылаться только в веб-слое. Избавьтесь от этой зависимости, удалив сеансы из DAO и сделав так, чтобы код JSF явно передал идентификатор пользователя.

После того, как это будет решено, ваши общие DAO должны будут принять идентификатор пользователя в качестве параметра, и в этом случае победит 'Это не проблема.

...