DAO de JavaEE6: ¿Debería ser @Stateless o @ApplicationScoped?

Question

Actualmente estoy creando una clase de acceso a datos EJB3 para manejar todas las operaciones de bases de datos en mi aplicación Java EE 6. Ahora, dado que Java EE 6 proporciona la nueva Annotation de ApplicationScoped, me pregunto qué estado debería tener mi EJB, o si debería ser sin estado.

¿Sería mejor dejar que el DAO sea un @Stateless Session Bean, o un @ApplicationScoped Bean? ¿Qué hay de @Singleton? ¿Cuáles son las diferencias entre estas opciones relacionadas con un DAO?

EDIT: estoy usando GlassFish 3.0.1 con la plataforma completa de Java EE 6

Answer 1

whould sea mejor dejar que el DAO ser un @Stateless bean de sesión, o un grano de @ApplicationScoped ? ¿Qué hay de @Singleton? ¿Cuáles son las diferencias entre estas opciones relacionadas con un DAO?

No utilizaría Beans de sesión sin estado para DAOs:

1. EJB se agrupan por el contenedor de modo que si usted tiene N instancias por la piscina y miles de mesas, sólo vamos a desperdiciar recursos (ni siquiera mencionar el costo en el momento del despliegue).

2. La implementación de DAO como SLSB alentaría el encadenamiento EJB, que no es una buena práctica desde el punto de vista de la escalabilidad.

3. No ataría la capa DAO a la API EJB.

El @Singleton introdujo en EJB 3.1 podría hacer las cosas un poco mejor, pero todavía no aplicaría DAOs como EJB. Prefiero usar CDI (y tal vez un estereotipo personalizado, vea this article por ejemplo).

O no usaría ningún DAO. El administrador de entidades de JPA es una implementación del patrón Domain Store y el ajuste del acceso a un Almacén de dominios en un DAO no agrega mucho valor.

Answer 2

@Pascal: En mi opinión, mi DAO no es "responsable" de la transacción o la seguridad, ya que el contenedor gestiona estos servicios. Solo estoy anotando los métodos en mi DAO (solo por seguridad, ya que las transacciones se manejan automáticamente). ¿Las anotaciones ya son "responsabilidad"?

Bien, entonces me haces repensar sobre mi diseño. Espero que esta bien y no demasiado fuera de tema, pero tal vez ayuda - esta es la forma en que estoy usando hoy JEE6:

• JSF tiene acceso a un CDI Bean,
• el CDI frijol accede a la DAO-EJB, que ¿la "lógica de negocios"
• por lo que actualmente mi única "lógica de negocios" es hacer CRUD, más tarde agregaré algunos otros EJB para tareas críticas como métodos asíncronos o servicios de temporizador.
• mi DAO es genérico y se utiliza la consulta Criterios JPA2 hacer typesafe consultas (sin condiciones) en todo
• Yo sé que no necesito un DAO para persistir/actualizar/eliminar (demasiado simple), pero necesito para mis consultas; así que simplemente los puse juntos

¿Hay algún problema con este enfoque?

Answer 3

Después de un replanteamiento, parece que DAO realmente no es el nombre correcto para lo que quería hacer. Tal vez realmente es una fachada, como dijo Pascal. Acabo de encontrar el ejemplo Netbeans Petstore - una aplicación de ejemplo JavaEE6, vea here - donde tienen un ItemFacade que es responsable de encontrar/crear/eliminar entidades de la base de datos. Es un Bean de sesión sin estado. Se ve así:

@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() { ... } 
} 

Así como conclusión no llamo mi DAO DAO más, pero en su lugar sólo por ejemplo PersonEJB (creo "PersonFacade" pueda ser mal interpretado) y hago también @Stateless, ya que creo el ejemplo de Netbeans se puede considerar como bien diseñado.