progra

acceder a la persistencia . Debido a que el objetivo principal de la DAO es la estricta separación de la persistencia
datos y la lógica de negocios, un DAO tiene que ser invocado desde un componente de lógica de negocio , y no
directamente desde la presentación . Un intento de invocar un DAO directamente del nivel de presentación es
la indicación frst que es probable que sea superfuous . Unservicio, o incluso Fachada Servicio , haría
probablemente hacer un mejor trabajo en este caso.
Repensar
En un entorno EJB 3/Java EE 5 que no tiene que utilizar el JDBC de bajo nivel para acceder a la
base de datos de más. Usted puede utilizar el , pero potente lenguaje de consulta JPA genérica , así como nativo
SQL para ir a buscar no sólo los objetos persistentes , pero también objetos detransferencia de datos e incluso primitiva
tipos de datos de la base de datos . Incluso es posible ejecutar update y delete sin
utilizando el API JDBC de bajo nivel. La APP viene con el EntityManager , que proporciona
funcionalidad de acceso a datos genéricos . El acceso no puede ser más sencillo . El EntityManager puede ser
se inyecta directamente a cualquier bean de sesión :
EntityManagermétodos son muy similares a las implementaciones de DAO clásicos (CRUD ) ,
excepto por el uso extensivo de Java SE 5 genéricos
( http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html ) (Java SE 5 y los genéricos por lo que
no estaban disponibles en el momento J2EE) .
El EntityManager es ya una abstracción y la encapsulación , así una mayor disociación es
no es necesario y podría serincluso contraproducente . La abstracción del proveedor de servicios es
con fugas , como todos los demás abstracción , pero la situación se Definitivamente no mejorar con un adicional de
capa de direccionamiento indirecto .
El EntityManager se puede considerar como una implementación genérica de la pauta de DAO . Se puede
ser utilizado como un DAO y ser inyectado a los servicios existentes .El uso intensivo de lenguaje de consulta JPA,
Sin embargo , sería borrar la expresividad de la lógica de negocio . La creación de consultas puede ser
fácilmente un factor fuera a constructores - o utilidad clases de consulta dedicados. Los servicios podrían heredar el
lógica de la consulta de una clase abstracta también.
En Java EE, el patrón DAO es opcional y ya no es la única forma deacceder al almacén de datos.
EntityManager como abstracción es sufciente para la mayoría de los proyectos de software de la casa . En productos
desarrollo , sin embargo , un dedicado DAO como una capa adicional de abstracción podría ser necesario .
No obstante , la introducción de una capa de este tipo sin requisito claro es siempre sospechas y
deben justificarse al de los requisitos duros .
Enresumen , en Java EE 6 , un dedicado DAO es una excepción y no la regla . El DAO puede a menudo
ser reemplazado con un EntityManager inyectado en un Servicio.
Convenciones
La puesta en práctica concreta de la interfaz CrudService va a ser inyectada en el
cliente (por ejemplo , un Servicio ) por el contenedor . El DI hizo las superfuous fábrica DAO . todo
Estrategias de DAO sólo se componende una interfaz de negocio y su implementación del bean ( una sesión
frijol ) . Esta estructura es válida para todas las estrategias y variaciones DAO . Además simplifcation con una
bean de sesión sin interfaz no es adecuado . La inyección directa de la aplicación DAO hace
las pruebas fuera del recipiente más difícil y la sustitución de la aplicación casi imposible .
La Figura 1 ilustra laestructura del patrón DAO .










Un genérico DAO se implementa una vez y se reutiliza a partir de diversos componentes. Por lo tanto, debe ser
colocado en un paquete genérico, por ejemplo:
... [Nombre_aplicación]. Integration.dataservices
Domain-specifc DAOs debe residir en el componente de negocio relacionado, por ejemplo:
[nombre_aplicación]. book.dataservices
o más corto:...