architecture - hastags - ¿Buenas prácticas para el patrón DAO?

hashtags diseño de interiores

Question

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

Quiero preguntar :

1. ¿La capa DAO realiza tareas relacionadas únicamente con el acceso a datos? ¿Qué pasa con cosas como la encapsulación de excepción?
2. ¿Hay algún otro patrón que pueda usarse para reemplazar este o mejor que este?
3. Creo que los modelos de dominio pojo y los scripts de transacción hacen que incluso un problema simple se complique, ¿es posible eliminar por completo la capa dao?

Answer 1

El acceso a los datos varía dependiendo de la fuente de los datos. El acceso al almacenamiento persistente, tal 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 planos, etc.) y la implementación del proveedor.

Utilice un objeto de acceso a datos (DAO) para abstraer y encapsular todo el acceso al origen 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 un almacén persistente como un RDBMS, un servicio externo como un intercambio B2B, un repositorio como una base de datos LDAP o un servicio comercial al que se accede a través del Protocolo Inter-ORB de Internet CORBA (IIOP) o sockets de bajo nivel. El componente empresarial que se basa en el DAO utiliza la interfaz más simple expuesta por el DAO para sus clientes. El DAO oculta completamente 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 empresariales. Esencialmente, el DAO actúa como un adaptador entre el componente y la fuente de datos.

Answer 2

El objetivo principal de dicha capa es proporcionar una abstracción del back-end de persistencia. sin embargo, la mayoría de las veces, debido a las especificidades del back-end de persistencia, la ocultación total no es posible; Un ejemplo típico es el manejo de consultas. Para consultar una base de datos 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 u otra cosa. Como consecuencia, la mayoría de las veces, este patrón falla.

Además, también está el tema, más molesto, de DAO / DTO. Luego se le pide que escriba una primera clase con sus datos, y luego una segunda copia de los datos de la primera sin ningún valor agregado solo por el bien del aislamiento de la capa.

Sin embargo, hay algunos trabajos que se han hecho en este campo. Para un micro-marco que he iniciado e implementado para google-app-engine, he hecho una pequeña lista de los llamados marcos dao que facilitan este código bastante mundano.

Tenga en cuenta que planeo, en el futuro, poder ofrecer una total transparencia a través de la definición del servicio gaedo, pero es solo una esperanza ;-) (y no es de su interés inmediato, supongo).

Answer 3

Idealmente, su capa DAO ''abstrae'' el acceso a algún sistema de almacenamiento de datos (base de datos, sistema de archivos, directorio LDAP, ...). Entonces, en ese sentido, se utiliza 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 o algún 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 escapen a capas superiores (aislamiento). Un buen punto de partida para pensar en esto es: ¿qué tendría que hacer si planeo reemplazar el componente (una base de datos, por ejemplo) al que mi capa DAO brinda 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 de 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, esto será mucho más fácil.

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