Я в настоящее время создаю Класс Доступа к данным EJB3 для обработки всех операций базы данных в моем Java EE, с 6 приложениями. Теперь, так как Java EE 6 обеспечивает новое ApplicationScoped
аннотация, интересно, что указывает, что мой EJB должен иметь, или если это должно быть не сохраняющим состояние.
Было бы лучше позволить ДАО быть a @Stateless
Боб сессии, или @ApplicationScoped
Боб? Что относительно @Singleton
? Каковы различия между этими опциями, связанными с ДАО?
Править: Я использую Glassfish 3.0.1 со всей платформой Java EE 6
Что лучше - позволить DAO быть @Stateless Session Bean, или @ApplicationScoped Bean? Как насчет @Singleton? Каковы различия между этими вариантами, связанными с DAO?
Я бы НЕ использовал Stateless Session Beans для DAO:
EJBs объединяются в пул контейнером, поэтому если у вас N экземпляров на пул и тысячи таблиц, вы просто потратите ресурсы впустую (не говоря уже о затратах во время развертывания).
Реализация DAO как SLSB будет способствовать созданию цепочек EJB, что не является хорошей практикой с точки зрения масштабируемости.
Я бы не стал привязывать уровень DAO к API EJB.
Введенный в EJB 3.1 @Singleton
может немного улучшить ситуацию, но я все равно не стал бы реализовывать DAO в виде EJB. Я бы предпочел использовать CDI (и, возможно, пользовательский стереотип, см. эту статью для примера).
Или я бы вообще не использовал DAO. Менеджер сущностей JPA является реализацией паттерна Domain Store, и обертывание доступа к Domain Store в DAO не добавляет особой ценности.
@Pascal: На мой взгляд, мой DAO не «отвечает» за транзакцию или безопасность, поскольку контейнер управляет этими службами. Я просто аннотирую методы в моем DAO (только для безопасности, поскольку транзакции обрабатываются автоматически). Аннотации уже «ответственны»?
Хорошо, ты заставляешь меня переосмыслить мой дизайн. Надеюсь, все в порядке и не слишком не по теме, но, возможно, это поможет - вот как я использую JEE6 сегодня:
Что-то не так с этим подходом?
После некоторого переосмысления кажется, что 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 может считаться хорошо продуманным.