Dao Vs Repository

Publicada en Publicada en Diseño de Software

Compartelo con tus amigos!

DAO (Data Access Object)

Este es el patrón mas usado para realizar la persistencia de los objetos de dominio, la forma mas común y básica de este patron es una clase que contiene las operaciones CRUD (Create, Read, Update, Delete):

interface IDao<T, TId> {
  T Get(TId id);
  IEnumerable<T> GetAll();
  void Create(T entity);
  void Update(T entity);
  void Delete(T entity);
}

Este patrón nos permite separar la lógica del negocio con respecto a la lógica de persistencia, de esta forma se pueden crear variedad de implementaciones de persistencia (usando ORM o ADO.Net) sin que lleguen a afectar al dominio. El problema es que mayormente este patrón no tiene una responsabilidad bien definida y muchos lo toman como una pasarela para hablar con la base de datos, creando un método para cada posible consulta que se realice o por cada actualización parcial:

interface IProductDao {
  Product Get(int id);
  IEnumerable<Product> GetAll();
  void Create(Product entity);
  void Update(Product entity);
  void Delete(Product entity);

  Product GetByCode(string Code);
  IList<Product> GetByCategory(Category category);
  void UpdatePrice(decimal price);
}

Como pueden imaginarse si se sigue este esquema se pueden llegar a tener un clase con muchisimos métodos y volverse inmanejable.

Por otro lado muchos sitios de internet, implementan este patrón cambiendole el sufijo de Dao a Repository y piensan que estan implementado este ultimo, el cual si bien es cierto es un patrón con el mismo objetivo, es diferente en cuanto a concepto se refiere.

Repository

Este patrón tiene una concepto mucho mas centrado “Un repositorio representa un conjunto conceptual de todos los objetos de una clase. Actúa como una colección, excepto que posee una capacidad de consulta más elaborada” (traducido del libro Design Domain Driven – Eric Evans).

Al tratarse de una representación de una colección, no se tienen métodos por cada posible consulta a la base de datos sino que se apoya en el patrón Specification para resolverlas, y tampoco requiere de un mecanismo de actualización de data ya que los cambios deben ser detectado automáticamente y ser persistidos sin que el dominio sepa de esta operación, para ello se apoya en el patrón UnitOfWork (quiza por ello es que los ORMs mas populares implementan estos patrones de forma conjunta)

interface IRepository<T> {
 T Get(Specification spec);
 IEnumerable<T> Query(Specification spec);
 void Add(T entity);
 void Delete(T entity);
}

Gracias a que Microsoft nos ha proporcionado un mecanismo de consulta de objetos (LINQ), la implementación de este patrón (y de Specification) se ha vuelto mas sencilla; e incluso muchas veces no es necesario implementarla ya que como mencione antes muchos ORMs ya lo implementan.

De estos 2 patrones y muchos más hablaremos este 23 de Mayo en el Cuarto Meetup a llevarse a cabo en Bellatrix.

Pueden separar su asistencia aqui:

https://www.meetup.com/es-ES/PeruNetDevelopment/events/239616201/

Saludos.

Compartelo con tus amigos!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *