Patrón DAO y PAtrón Active Record

Hay mucha literatura sobre el clásico patrón DAO, en este post vamos a comparar el enfoque del patrón DAO y el patrón Active Record para resolver el acceso a nuestra capa de persistencia.

El Patrón DAO:

· Es un patrón de los denominados “Core J2EE Patterns” (vamos, que tiene sus añitos :))

· Su objetivo es independizar de la fuente de datos a la aplicación ocultando los detalles de implementación haciendo que el interfaz no cambie aunque cambie la forma de resolverlos (llegado al extremo podríamos cambiar de una base de datos relacional a una base de datos NoSQL o a la persistencia en ficheros y el resto de la aplicación no se enteraría).

· Se ve bien en este ejemplo

· En cuanto a los actores que intervienen en este patrón tendríamos:

o BusinessObject Es el objeto que quiere acceder a la fuente de datos para poder almacenar o consultar datos

o DataAccessObject: Abstrae al BusinessObject de los detalles del acceso a la fuente de datos

o DataSource: Representa la implementación de la fuente de datos

o Transfer Object: es un objeto intermedio entre el BusinessObject y el DataAcessObject

El patrón Active Record

· En este patrón se sigue una aproximación Domain Rich Model, en la que la propia Clase que representa la fuente de datos es capaz de persistirse, buscarse,…

· Una implementación muy conseguida es la que nos ofrece Spring Roo en la que Roo genera unos aspectos asociados a las entidades JPA que permiten que puedan buscarse, persistirse, como:

 

Podéis leer más aquí

· Otra implementación en Java del patrón es el framework ActiveRecord:

 

Cuándo usar DAO y ActiveRecord

Una vez que tenemos las dos posibilidades la dificultad radica en cuándo elegir cada uno, aunque es difícil dar “normas” vamos a intentar dar algunas recomendaciones:

· El Patrón ActiveRecord es más simple, El Patrón DAO crea una capa de abstracción que en muchos casos no es necesaria: por ejemplo si una UI Web sólo se encarga de buscar, persistir, borrar los datos de una tabla necesitamos un DAO o nos basta con usar el ActiveRecord desde el controlador?

· Una clase ActiveRecord no debería ser parámetro de un Servicio publicado ya que estaríamos acoplando la estructura de mi base de datos con los parámetros del Servicio. Otra discusión aparte es que debe ser un servicio 🙂

· Para algunos el patrón ActiveRecord mezcla capas (negocio y persistencia), para otros al contrario ofrece un modelo de dominio rico

Y volviendo a referirnos a Spring Roo hasta la versión 1.2 Spring Roo sólo soportaba el patrón ActiveRecord para la persistencia, desde la versión 1.2 se pueden usar ambos enfoques

Bueno, siendo estrictos ya no se usaría el patrón DAO si no el patrón Repository que crea un nivel de abstracción superior al del DAO.