El patrón Repository encapsula la lógica de acceso a la fuente de datos (BD, API, etc.), proporcionando una capa de abstracción entre la lógica de dominio y el mecanismo de almacenamiento de datos. El objetivo principal es ocultar los detalles de implementación del almacenamiento y garantizar el funcionamiento con una colección de objetos del dominio.
Ventajas:
Ejemplo de código en C#:
public interface IUserRepository { User GetById(int id); void Add(User user); } public class UserRepository : IUserRepository { private readonly DbContext _context; public UserRepository(DbContext context) { _context = context; } public User GetById(int id) => _context.Users.Find(id); public void Add(User user) => _context.Users.Add(user); }
Características clave:
¿Deben los Repositorios conocer la estructura de la base de datos?
No. El Repositorio debe operar sobre objetos del dominio y ocultar los detalles del almacenamiento. Una capa de acceso a datos separada se encarga del mapeo al esquema de la BD.
¿Se puede mezclar la lógica de negocio dentro de la clase Repositorio?
No. Esto viola la Separación de Preocupaciones: el Repositorio solo se encarga de obtener/guardar datos. La lógica de negocio debe extraerse a servicios/objetos de dominio.
¿Repository y DAO son lo mismo?
No exactamente. DAO es ortogonal al patrón Repository, trabaja a nivel de tablas y registros, mientras que el Repository trabaja con objetos de lógica de negocio. Repository abstrae colecciones de entidades de negocio, DAO está más cerca de la infraestructura.