JavaEE6 DAO: должно быть @Stateless или @ApplicationScoped? - PullRequest
18 голосов
/ 11 июля 2010

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

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

РЕДАКТИРОВАТЬ: Я использую Glassfish 3.0.1 с полной платформой Java EE 6

Ответы [ 3 ]

15 голосов
/ 12 июля 2010

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

Я бы НЕ использовал Session Beans без сохранения состояния для DAO:

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

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

  3. Я бы не стал связыватьУровень DAO для EJB API.

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

Или я бы вообще не использовал DAO.Диспетчер сущностей JPA представляет собой реализацию шаблона Domain Store , и доступ к хранилищу доменов в DAO не имеет большого значения.

1 голос
/ 14 июля 2010

После некоторого переосмысления кажется, что DAO на самом деле не подходящее название для того, что я хотел сделать. Может быть, это действительно Фасад, как сказал Паскаль. Я только что нашел пример Netbeans Petstore - пример приложения 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 можно также рассмотреть -разработана.

0 голосов
/ 12 июля 2010

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

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

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

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

...