Patrón DAO
DAO son las siglas de Data Access Object, pero para entenderlo mejor vayamos a las fuentes J2EE Core Paterns:
"Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data. (...)
The DAO implements the access mechanism required to work with the data source.(...)
The DAO completely hides the data source implementation details from its clients."
En román paladino: el DAO es el responsable de componer los datos de sistemas externos, en caso de una base de datos, será el responsable de componer y ejecutar las consultas SQL necesarias para hacer las operaciones. Por ejemplo:
interface IFacturaDAO
{
Factura Get(int id);
void Save(Factura factura);
void Delete(Factura factura);
ICollection<Factura> getFacturasSinCobrar();
}
Más o menos este es el ejemplo clásico, un interfaz que nos permite realizar como mínimo las operaciones de un CRUD.Patrón Repositorio
Si para el patrón DAO consultamos J2EE Core Patterns, para la definición del repositorio debemos acudir a Martin Fowler:
"Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects"
Aunque la definción de los colaboradores de Fowler (Edward Hieatt y Rob Mee) es breve y clara, creo que deja muchos interrogantes abiertos. Únicamente indica que se debe implementar un interfaz similar al de una colección y que por debajo ya se encargará acceder a los datos.
interface IFacturaRepositoy : ICollection<Factura>
{
ICollection<Factura> GetFacturasSinCobrar();
}
En este ejemplo, además del interfaz de ICollection, el respositorio de facturas implementa una consulta que recupera las facturas sin cobrar. Pero al implementar ICollection hay que sopesar si se debe implementar el método Clear(), yo personalmente no lo haría ;)
Las ¿consultas son reglas de negocio? ¿o es parte del acceso a datos?
Si os fijáis en los ejemplos anteriores, tanto el DAO como el repositorio de factura exponen Este es un debate muy importante que condiciona el desarrollo de la capa de acceso a datos y la implementación de las reglas de negocio.
Utilices DAOs o Repositorios, si crees que las consultas forman parte de las reglas de negocio y quieres mantener la independencia entre negocio y acceso a datos, ¿como puedo escribir las querys, sin usar SQL en la capa de negocio? La solución nos la ofrece otra vez Fowler con el patrón Query Object: "An object that represents a database query"
Si crees que las consultas son solo consultas o que programar una implementación de query object es un esfuerzo innecesario, siempre puedes escribir las consultas dentro de tu DAO (incluso dentro del repositorio, estirando un poco la interpretación del patrón).
Algunos de vosotros pensareis, este Query Object se parece mucho a un criteria de Hibernate. Sí, tenéis razón, se podría decir que el api de criteria es una implementación de Query Object. ¿Y por qué no usarlo en la capa de negocio? Porque si usas criteria fuera de la capa de acceso a datos, estas añadiendo una referencia a Hibernate (a un mecanismo de acceso a datos) en tu capa de negocio. Pero de esto hablaremos más tarde en este post (la tercera vía)
En .Net Linq nos permite hacer implementaciones limpias del patrón repositorio. Linq nos permite hacer consultas sobre colecciones IQueriables y está soportado por el framework. Pero ¿exponer IQueriable fuera de nuestro acceso a datos nos permite mantener a nuestras entidades ignorantes de los mecanismos de persistencia? Sí y no.
En teoría sí ya que Linq forma parte del framework, pero en la realidad es que, de esta forma, se limita el número de opciones a disposición del programador: NHibernate, Entity Framework, o algun otro sistema que soporte Linq. Porque el coste de implementar IQueriable en un sistema que utiliza Ado.Net es altísimo y no creo que merezca la pena.
En definitiva se podría decir que se aplican las reglas de negocio en dos momentos de la aplicación:
- al aplicar condiciones para recuperar los datos (recuperar las facturas no pagadas)
- Antes de persistir los cambios en la base de datos.
Tercera vía: los ORM ya nos abstraen de la base de datos.
La gran ventaja de los patrones DAO y repositorio es que abstraen al resto del código de la base de datos, mediante estos mecanismos, si cambia la base de datos no tenemos que tocar la implementación de las reglas de negocio.
Al utilizar ORMs como Hibernate o Entity Framework la abstracción con la base de datos está asegurada. Si ya tenemos una capa de abstracción ¿por qué añadir otra? evitar perder funcionalidad que ofrece el ORM directamente. De esta forma el código es más seco (DRY), incluso se podría decir que cumple el principio de responsabilidad única, ya que el encargado de guardar el objeto es el ORM. Por último, al no tener DAOs ya no tienes la duda de ¿la consulta es una regla de negocio o forma parte del acceso a datos? al usar el ORM directamente también se usan directamente sus mecanismos de consulta.
Reflexiones finales
En una aplicación empresarial, donde es importante tener organizado el código, donde muchas cosas pueden cambiar a petición del cliente y además el equipo estará formado por varias personas, intentaría mantener la capa de acceso a datos completamente aislada, es decir que usaría DAO o Repositorio.
En .Net dudaría si implementar repositorios exponiendo IQueriables ya que muchos controles del framework, paginan y ordenan estas colecciones.
En Java utilizaría DAOs sin lugar a dudas, no implementaría Query Objects, dejando las consultas en el DAO.
Si estas en una empresa con personas que programan en Java y .Net un DAO con hibernate creo que es la mejor solución.
El uso directo de un ORM lo dejaría en proyectos pequeños o medianos, con una persona desarrollando y que requieran cambios rápidos. Aunque eso es un riesgo en un entorno empresarial, ya que desaparece esa persona, y lo que para unos es orden, para otros es caos.
¿Y tu qué opinas? ¿cómo plantearías la estrategia de acceso a datos de una aplicación?
