Patrón DAO Como implementarlo & sus caracteristicas

En la actualidad prácticamente cualquier servicio tecnológico e incluso aunque no sea tecnológico requiere consumir una fuente de datos, aquellas fuentes generalmente son bases de datos ó relacionales ó no relacionales, pero sucede que muchas veces tenemos mas de una fuente de datos y nuestro servicio requiere consumir esa fuente masiva de datos, lo que nos obligaría a matarnos la cabeza reforzando código, nos llevaría mas tiempo y esfuerzo, en base a esto nació el patrón DAO (Data Acces Object) el cual como su nombre lo dice se implementa para consumir una o mas fuentes de datos mas concretamente nos permite separar la capa de datos de la capa Bussiness.


El patrón DAO nos propone separar la capa de datos completamente de la capa de negocio dado que este proporcionara los métodos para acceder a los datos y manipularlos, métodos insert, create, update, delete de este modo la lógica de negocio no tendría que preocuparse de la lógica para acceder a los datos.

Componentes básicos

  • BusinessObject: representa un objeto con la lógica de negocio.
  • DataAccessObject: representa una capa de acceso a datos que oculta la fuente y los detalles técnicos para recuperar los datos.
  • TransferObject: este es un objeto plano que implementa el patrón Data Transfer Object (DTO), el cual sirve para transmitir la información entre el DAO y el Business Service.
  • DataSource: representa de forma abstracta la fuente de datos, la cual puede ser una base de datos, Webservices, LDAP, archivos de texto, etc.

Veamos un ejemplo sencillo...

Ejemplo 1.1:

Supongamos que el código de acceso a los recursos de datos (normalmente bases de datos relacionales) está incluido dentro de clases que tienen además otras responsabilidades diferentes. Un caso clásico es la inclusión de código JDBC o etiquetas de JSTL en un JSP para acceder a una base de datos. Para mejorar la modularidad y la mantenibilidad del sistema, es recomendable encapsular la persistencia de datos en una capa separada.

Análisis del problema

  • Se quiere un API de acceso uniforme a los recursos de datos, independientemente de que sean bases de datos relacionales, directorios LDAP, ficheros XML
  • Se requiere implementar persistencia de datos a la hora de desarrollar la aplicación
  •  La implementación de la persistencia debería estar separada del resto de la aplicación

Solución

Utilizar un patrón DAO (Data Access Object). El DAO encapsula el acceso a la/s fuente/s de datos (DataSources), de manera que los detalles son transparentes para el cliente. Típicamente el DAO trabaja con un ResultSet resultado de una operación JDBC ocultando este ResultSet al cliente. Aquí el cliente sería cualquier objeto de la aplicación que necesitara la persistencia de datos. La siguiente figura muestra el diagrama de clases de este patrón. Como se ve, proporciona las típicas operaciones CRUD (Create, Read, Update, Delete).

La comunicación de datos entre cliente y DAO se hace a través de objetos Java (que siguen el patrón Transfer Objects - 2.2.4). Así, por ejemplo, cuando se invoca a create, update o delete el cliente le pasa al DAO un Transfer Object con los datos del objeto con el que operar, y cuando se llama a read el DAO devuelve un Transfer Object.

En general, se usaría un DAO distinto para cada objeto del modelo de objetos de la aplicación. Así, si hay por ejemplo clientes y pedidos, habría un ClienteDAO y un PedidoDAO.

Estrategias de implementación

  • Implementación básica: el DAO encapsula las llamadas al API para el acceso a la fuente de datos (típicamente JDBC) y devuelve objetos Java (Transfer Objects - 2.2.4).
  • Factoría de DAOs: como en general será necesario crear varios DAOs distintos (ClienteDAO, PedidoDAO, ...), para hacerlo de manera flexible se puede utilizar el patrón Factory del GoF.

¿Bueno y de esto tan bonito que nos resulta o que ganamos?

Pues principalmente en la transparencia en el acceso a datos por parte del cliente. Además, se pueden cambiar las fuentes de datos de manera también transparente(por ejemplo de MySQL a Oracle o incluso de una base de datos relacional a un fichero XML, por ejemplo).

Al igual que en proporcionar una visión orientada a objetos de las fuentes de datos, al igual que reducimos la complejidad para que el cliente entienda el código, entienda nuestro trabajo.

Pero no termina ahí, puesto que también tenemos algunas cositas que podrían considerarse negativas las cuales vendrían siendo que a la hora de desarrollar tendríamos que añadir una capa extra, lo que implica un esfuerzo extra de implementación y prueba al igual que el uso de estrategias complejas nos consume mas tiempo y esfuerzo de estructuramiento e implementación.

|También te puede interesar: Aprende a implementar Sockets en java, ejemplo sencillo

Conclusiones

El patrón DAO es sin lugar a duda uno de los patrones mas utilizados en la actualidad a la hora de desarrollar ya que su versatilidad, su agilidad y su flexibilidad para trabajar con diferentes fuentes de datos al mismo tiempo resulta muy cómoda y su implementación es muy fácil, además el hecho de tener un patrón para separar las capas de datos y de negocio resulta muy increíble porque nos facilita la comprensión de código y nuestro flujo de trabajo se vuelve mas cómodo.


Comenta si te ha quedado alguna duda, ¡comparte.!




Comentarios

Artículos interesantes

Arrays en Java

JOINS en MySQL ¡Bien Explicado!

Que es Java Spring Boot

Que es PL/SQL Ejemplos Básicos

Aprende a implementar Sockets en java, ejemplo sencillo

¿Qué son los Sockets en java y como funcionan?