EJB3 Business Logic Patterns & Practices

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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