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

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

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

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

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


java jpa jakarta-ee ejb-3.0 stateless-session-bean
person Kris Nuttycombe    schedule 30.10.2008    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

person perilandmishap    schedule 07.11.2008

arrow_upward
0
arrow_downward

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

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

person G B    schedule 30.10.2008
comment
Под системными службами вы имеете в виду такие вещи, как контекст персистентности, транзакции и т. Д.? Я спрашиваю, потому что мое приложение использует ряд внешних сервисов, которым требуются внедренные зависимости (конфигурация подключения и прочее), с которыми я работаю с Guice. - person Kris Nuttycombe; 30.10.2008