Le modèle Repository encapsule la logique d'accès à la source de données (BD, API, etc.), fournissant une couche d'abstraction entre la logique métier et le mécanisme de stockage des données. L'objectif principal est de masquer les détails de l'implémentation du stockage et de garantir le fonctionnement avec une collection d'objets du domaine.
Avantages :
Exemple de code 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); }
Caractéristiques clés :
Le Repository doit-il connaître la structure de la base de données ?
Non. Le Repository doit opérer sur des objets du domaine et masquer les détails du stockage. Une couche d'accès aux données distincte s'occupe de la cartographie sur le schéma de la base de données.
Peut-on mélanger la logique métier à l'intérieur de la classe Repository ?
Non. Cela violerait le principe de séparation des préoccupations : le Repository est uniquement responsable de la récupération/de la sauvegarde des données. La logique métier doit être déportée vers des services/objets de domaine.
Repository et DAO, est-ce la même chose ?
Pas tout à fait. Le DAO est orthogonal au modèle Repository, il fonctionne au niveau des tables et des enregistrements, tandis que le Repository opère avec des objets de la logique métier. Le Repository abstrait les collections d'entités métier, le DAO est plus proche de l'infrastructure.