java - cdi beans xml

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

Question

Actualmente estoy creando una clase de acceso a datos EJB3 para manejar todas las operaciones de base de datos en mi aplicación Java EE 6. Ahora, ya que Java EE 6 proporciona la nueva anotación 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 sesión sin estado o un bean de aplicación? ¿Qué pasa con @Singleton ? ¿Cuáles son las diferencias entre estas opciones relacionadas con un DAO?

EDITAR: Estoy usando Glassfish 3.0.1 con la plataforma completa Java EE 6

Answer 1

¿Por qué sería mejor dejar que el DAO sea un bean de sesión sin estado o un bean de aplicación? ¿Qué pasa con @Singleton? ¿Cuáles son las diferencias entre estas opciones relacionadas con un DAO?

NO usaría Stateless Session Beans para los DAO:

1. Los EJB están agrupados por el contenedor, por lo que si tiene N instancias por grupo y miles de tablas, simplemente va a desperdiciar recursos (ni siquiera mencionar el costo en el momento del despliegue).

2. Implementar DAO como SLSB fomentaría el encadenamiento de EJB, lo 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 de EJB.

El @Singleton introducido en EJB 3.1 podría mejorar un poco las cosas, pero todavía no implementaría los DAO como EJB. Preferiría usar CDI (y tal vez un estereotipo personalizado, vea este artículo por ejemplo).

O no usaría los DAO en absoluto. El administrador de entidades de JPA es una implementación del patrón de Domain Store y el acceso envolvente a un Domain Store 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 administra 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"?

De acuerdo, me haces volver a pensar en mi diseño. Espero que esté bien y no demasiado fuera de tema, pero tal vez ayude, así es como estoy usando JEE6 hoy:

• JSF accede a un CDI Bean,
• el CDI Bean accede al DAO-EJB que hace la "lógica de negocios"
• por lo que actualmente mi única "lógica de negocios" es CRUD, luego agregaré algunos otros EJB para tareas críticas como métodos asíncronos o Servicios de temporizador.
• mi DAO es genérico y utiliza la consulta de criterios JPA2 para realizar consultas de tipos seguros (sin cadenas)
• Sé que no necesito un DAO para persistir / actualizar / eliminar (demasiado simple), pero lo necesito para mis consultas; así que simplemente los puse juntos

¿Hay algo mal con ese enfoque?

Answer 3

Después de un replanteamiento, parece que DAO no es realmente el nombre correcto para lo que quería hacer. Tal vez realmente sea una fachada, como dijo Pascal. Acabo de encontrar el ejemplo de Netbeans Petstore, una aplicación de ejemplo de 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 como esto:

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

Entonces, como conclusión, ya no llamo a mi DAO DAO, sino que, por ejemplo, PersonEJB (creo que "PersonFacade" podría ser mal interpretado) y también lo hago como @Stateless, ya que creo que el ejemplo de Netbeans puede considerarse bien diseñado.