¿La mejor práctica para el patrón DAO?

Question

He visto muchos códigos usar un patrón de servicio-dao, no sé el origen de este patrón. Obliga al servicio de llamada de la capa frontal y luego delega parte de la tarea de servicio en dao.

quiero preguntar:

capa

1. ¿El DAO no puramente acceso a datos tarea relacionada? ¿Qué pasa con cosas como la encapsulación de excepciones?
2. ¿Se puede utilizar algún otro patrón para reemplazar esto o mejor que esto?
3. Creo que los modelos de dominio pojo y los scripts de transacciones hacen que incluso el problema simple se vuelva complicado, ¿es posible eliminar completamente la capa dao?

Answer 1

Lo ideal es que su capa DAO 'abstraiga' el acceso a algún sistema de almacenamiento de datos (base de datos, sistema de archivos, directorio LDAP, ...). Entonces, en ese sentido, se usa solo para tareas relacionadas con el acceso a datos. Sin embargo, también podría tener una capa DAO que acceda a un servicio web u otro componente externo a su aplicación. Ese es el punto clave, proporciona acceso a algún componente externo.

La idea principal es que no hay detalles de implementación de su capa DAO que escape a las capas superiores (aislamiento). Un buen punto de partida para pensar sobre esto es: ¿qué tendría que hacer si planeo reemplazar el componente (una base de datos, por ejemplo) a la que mi capa DAO proporciona acceso? Por ejemplo, tiene algunos datos dentro de archivos XML y planea migrar los datos a una base de datos.

Supongamos que tiene todo tipo de excepciones relacionadas con XML que escapan a su capa DAO. Entonces se vuelve bastante difícil migrar su capa XML a una capa de base de datos. Sin embargo, si ha encapsulado todos los detalles de implementación de su capa DAO, será mucho más fácil.

Al final, se trata de mantener el código. Cuantas menos dependencias tenga en los detalles de implementación de una capa específica (servicios, DAO, ...), mejor será su código.

Answer 2

El objetivo principal de dicha capa es proporcionar abstracción del componente de persistencia. sin embargo, la mayoría de las veces, debido a las características específicas del back-end de persistencia, no es posible ocultar por completo; Un ejemplo típico es el manejo de consultas. Para consultar un DB usando hibernación, escribirá algún tipo de código de consulta (usando HQL, API de consulta, ...) y un paradigma totalmente diferente cuando use JCR, una BigTable o alguna otra cosa. Como consecuencia, la mayoría de las veces, este patrón falla.

Además, también está la cuestión más molesta de DAO/DTO. Luego lo presionan para escribir una primera clase que contenga sus datos, luego una segunda copia de datos de su primer sin ningún valor agregado solo por el aislamiento de capas.

Sin embargo, hay algo de trabajo que se ha hecho en este campo. Para un micro-framework que he comenzado e implementado para google-app-engine, he creado un little list de los denominados marcos dao que facilitan este código más bien mundano.

Aviso Planeo, en el futuro, poder ofrecer total transparencia a través de la definición del servicio gaedo, pero es solo una esperanza ;-) (y no es de interés inmediato para usted, supongo).

Answer 3

El acceso a los datos varía según la fuente de los datos. El acceso al almacenamiento persistente, como a una base de datos, varía mucho según el tipo de almacenamiento (bases de datos relacionales, bases de datos orientadas a objetos, archivos sin formato, etc.) y la implementación del proveedor.

Utilice un objeto de acceso a datos (DAO) para abstraer y encapsular todo el acceso a la fuente de datos. El DAO gestiona la conexión con la fuente de datos para obtener y almacenar datos.

El DAO implementa el mecanismo de acceso requerido para trabajar con la fuente de datos. La fuente de datos podría ser una tienda persistente como un RDBMS, un servicio externo como un intercambio B2B, un repositorio como una base de datos LDAP o un servicio empresarial al que se accede a través del protocolo CORBA Internet Inter-ORB (IIOP) o tomas de bajo nivel. El componente comercial que se basa en DAO usa la interfaz más simple expuesta por DAO para sus clientes. El DAO oculta por completo los detalles de implementación de la fuente de datos de sus clientes. Debido a que la interfaz expuesta por el DAO a los clientes no cambia cuando cambia la implementación de la fuente de datos subyacente, este patrón permite que el DAO se adapte a diferentes esquemas de almacenamiento sin afectar a sus clientes o componentes comerciales. Esencialmente, el DAO actúa como un adaptador entre el componente y la fuente de datos.