ДАО JavaEE6: это должен быть @Stateless или @ApplicationScoped?

Я в настоящее время создаю Класс Доступа к данным EJB3 для обработки всех операций базы данных в моем Java EE, с 6 приложениями. Теперь, так как Java EE 6 обеспечивает новое ApplicationScoped аннотация, интересно, что указывает, что мой EJB должен иметь, или если это должно быть не сохраняющим состояние.

Было бы лучше позволить ДАО быть a @Stateless Боб сессии, или @ApplicationScoped Боб? Что относительно @Singleton? Каковы различия между этими опциями, связанными с ДАО?

Править: Я использую Glassfish 3.0.1 со всей платформой Java EE 6

20
задан ktulinho 13 February 2019 в 18:31
поделиться

3 ответа

Что лучше - позволить DAO быть @Stateless Session Bean, или @ApplicationScoped Bean? Как насчет @Singleton? Каковы различия между этими вариантами, связанными с DAO?

Я бы НЕ использовал Stateless Session Beans для DAO:

  1. EJBs объединяются в пул контейнером, поэтому если у вас N экземпляров на пул и тысячи таблиц, вы просто потратите ресурсы впустую (не говоря уже о затратах во время развертывания).

  2. Реализация DAO как SLSB будет способствовать созданию цепочек EJB, что не является хорошей практикой с точки зрения масштабируемости.

  3. Я бы не стал привязывать уровень DAO к API EJB.

Введенный в EJB 3.1 @Singleton может немного улучшить ситуацию, но я все равно не стал бы реализовывать DAO в виде EJB. Я бы предпочел использовать CDI (и, возможно, пользовательский стереотип, см. эту статью для примера).

Или я бы вообще не использовал DAO. Менеджер сущностей JPA является реализацией паттерна Domain Store, и обертывание доступа к Domain Store в DAO не добавляет особой ценности.

15
ответ дан 30 November 2019 в 01:18
поделиться

@Pascal: На мой взгляд, мой DAO не «отвечает» за транзакцию или безопасность, поскольку контейнер управляет этими службами. Я просто аннотирую методы в моем DAO (только для безопасности, поскольку транзакции обрабатываются автоматически). Аннотации уже «ответственны»?

Хорошо, ты заставляешь меня переосмыслить мой дизайн. Надеюсь, все в порядке и не слишком не по теме, но, возможно, это поможет - вот как я использую JEE6 сегодня:

  • JSF обращается к компоненту CDI,
  • компонент CDI обращается к DAO-EJB, который выполняет «бизнес-логику»
  • , поэтому в настоящее время моя единственная «бизнес-логика» - это CRUD, позже я добавлю некоторые другие EJB-компоненты для критических задач, таких как асинхронные методы или службы таймера.
  • мой DAO является универсальным и использует запрос критериев JPA2 для выполнения типизированных запросов (вообще без строк)
  • Я знаю, что мне не нужен DAO для сохранения / обновления / удаления (слишком просто), но мне нужно это для моих запросов; так что я просто собрал их вместе

Что-то не так с этим подходом?

0
ответ дан 30 November 2019 в 01:18
поделиться

После некоторого переосмысления кажется, что DAO на самом деле не подходящее название для того, что я хотел сделать. Может быть, это действительно фасад, как сказал Паскаль. Я только что нашел Netbeans Petstore Example - пример приложения JavaEE6, см. здесь - где у них есть ItemFacade , который отвечает за поиск / создание / удаление сущностей из базы данных. Это сеансовый компонент без сохранения состояния. Выглядит так:

@Stateless
public class ItemFacade implements Serializable {
    @PersistenceContext(unitName = "catalogPU")
    private EntityManager em;

    public void create(Item item) { ... }
    public void edit(Item item) { ... }
    public void remove(Item item) { ... }
    public Item find(Object id) { ... }
    public List<Item> findAll() { ... }
    public List<Item> findRange(int maxResults, int firstResult) { ... }
    public int getItemCount() { ... }
}

Итак, в качестве заключения я больше не называю свой DAO DAO, а вместо этого просто, например, PersonEJB (я думаю, что «PersonFacade» может быть неправильно понят) и сделать его также @Stateless, поскольку я думаю, что пример Netbeans может считаться хорошо продуманным.

2
ответ дан 30 November 2019 в 01:18
поделиться
Другие вопросы по тегам:

Похожие вопросы: