Следует ли внедрять EntityManager в EJB?

Я разрабатываю очень простое веб-приложение с веб-службой REST, которая использует JPA для взаимодействия с базой данных PostgreSQL и работает в TomEE.

Я не считаю, что у меня есть необходимость (или желание) вручную управлять жизненным циклом EntityManager, поэтому я планирую перенести эту рутинную работу на TomEE с помощью EntityManagers, управляемых контейнером (вероятно, с областью действия транзакции).

Я не считаю, что у меня есть потребность (или желание) вручную управлять транзакцией JTA, которую требуют EntityManagers, управляемые контейнером.

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

Является ли мой лучший вариант для каждого класса DAO EJB, который использует аннотацию @PersistenceContext для получения ссылки на EntityManager? Если да, то каким типом EJB должны быть DOA? Я видел примеры/блоги, в которых предлагалось использовать stateless, stateful, singleton и даже полностью забыть о DAO, внедрив EntityManager в сами веб-сервисы. Каков наилучший способ справиться с этим?


jpa ejb
person Ed LaFave    schedule 18.02.2016    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Каждый DAO должен быть сессионным компонентом без сохранения состояния, в который вводятся ссылки на БД.

Было бы лучше иметь GenericDAO для выполнения операций CRUD через EntityManager, чтобы избежать репликации кода вокруг EJB.

Обычно я предпочитаю также создавать один EJB для каждого клиента Ws, если необходимо вызвать какую-либо службу.

В случае предоставления сервера Ws я всегда ввожу экземпляр EJB, который мне нужен, а не ввожу экземпляр EntityManager, поскольку было бы неплохо иметь единую точку доступа.

person antoniodvr    schedule 19.02.2016
comment
EntityManager уже предоставляет операции CRUD; зачем вам заключать его в более (избыточный) код? - person Steve C; 19.02.2016
comment
Какой смысл снова и снова вводить EntityManager, если у вас уже есть DAO для этой области? Тогда, внедряя его везде, вы не можете знать, где меняются данные... У вас не будет ни одной точки доступа к ним. - person antoniodvr; 19.02.2016

arrow_upward
0
arrow_downward

Превращение класса в EJB даст классу некоторые функции, которые есть у EJB и которыми управляет Container, такие как управление транзакциями, безопасность потоков, безопасность и т. д.

В книге Ejb в действии говорится, что рекомендуется иметь простой класс DAO (не EJB), который работает с EntityManager. Классы DAO не должны участвовать в управлении транзакциями и других функциях, которые есть у EJB, вместо этого всегда должен быть EJB, который использует класс DAO (с использованием аннотации @Inject), а другие службы, такие как веб-службы REST или SOAP, должны вызывать этот EJB, который использует DAO, который нам нужен.

Преобразование всех классов, таких как классы DAO и служебные классы, в EJB возложит бремя на плечи контейнера и затруднит управление всеми EJB.

person AliReza19330    schedule 24.04.2016