EJB3 Шаблоны и практика бизнес-логики

Question

Я нахожусь в процессе разработки многоуровневого приложения для финансовой обработки на Java с использованием EJB3 (Hibernate + Glassfish для уровня приложений и веб-сервисов, Lift on Glassfish для веб-интерфейса), и я борюсь с вопросом где поставить мою бизнес-логику.

Когда этот проект начался, нашей первой идеей было поместить большую часть нашей бизнес-логики в сессионные компоненты без сохранения состояния. Однако с течением времени мы обнаружили, что внедрение зависимостей, предоставляемое EJB-инфраструктурой, слишком ограничивало, поэтому большая часть нашей бизнес-логики оказалась в POJO, которые собраны Guice в методе @PostConstruct сессионных компонентов без сохранения состояния. , Этот прогресс привел к фрагментации нашей бизнес-логики между сессионными компонентами и POJO, и я пытаюсь найти подход для исправления этого.

Изначально мы пытались заставить наш веб-уровень использовать удаленные интерфейсы сессионных компонентов для выполнения некоторых функций, доступных как из пользовательского интерфейса, так и из уровня веб-службы, который предоставляется @ WebService-аннотированными сессионными компонентами без сохранения состояния. Это оказалось кошмаром с точки зрения персистентности и производительности, потому что наш граф сущностей может вырасти довольно большим, и повторное присоединение графа отсоединенных сущностей к контексту персистенции оказалось очень подверженным ошибкам, поэтому наше решение состояло в том, чтобы начать просто передавать объект идентификаторы вокруг и поиск объектов из базы данных, где бы они ни были нужны.

Мой основной вопрос заключается в следующем: какие принципы и рекомендации вы можете предложить для принятия решения о том, должна ли бизнес-логика использоваться в сессионном компоненте или в POJO? Когда имеет смысл передавать сущностные бины, учитывая сложный граф объектов?

Answer 1

Я боролся с этим при создании веб-приложения с использованием JPA, EJB3 и Wicket. Поскольку удары по моей базе данных с помощью повторяющихся запросов были более масштабируемыми, чем хранение большого количества больших объектов в памяти, я решил передавать только их идентификаторы, а не сам объект.

Wicket и его концепция моделей были во многом связаны с этим решением. Их loadableDetachableModel очищает сущности, когда они не используются, при этом все еще удерживая идентификатор. Внедрен метод load (), который знает, как получить объект, когда он снова нужен, в моем случае, вызывая сессионный компонент без сохранения состояния; и метод persist () вызывает bean-компонент без сохранения состояния для сохранения изменений. Этот модельный класс - это то, что я действительно пропускаю. Wicket обрабатывает только логику, относящуюся к отображению и проверке ввода, и мне нужно только вставить ejb в классы модели. Возможно, вы могли бы создать нечто подобное в своем приложении (я понятия не имею, что может предложить лифт ...).

Это хорошо сработало для меня, но у меня нет особенно сложной бизнес-логики, и я могу выделить любые изменения, которые необходимо сохранить, в небольшие блоки логики и отдельные страницы.

Answer 2

Всякий раз, когда вам нужно много «системных» сервисов (инъекций и т. Д.), Используйте bean-компонент без сохранения состояния. В противном случае - POJOs. POJO гораздо более гибкие.

Однако простые (accessor?) Методы (например, в веб-сервисах и bean-компонентах) могут просто выполнить простую работу и вернуть результаты.