Il modello Repository incapsula la logica di accesso alle fonti di dati (DB, API, ecc.), fornendo uno strato di astrazione tra la logica di dominio e il meccanismo di archiviazione dei dati. L'obiettivo principale è nascondere i dettagli di implementazione dell'archiviazione e garantire il funzionamento con una collezione di oggetti del dominio.
Vantaggi:
Esempio di codice in 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); }
Caratteristiche chiave:
Il Repository deve conoscere la struttura del database?
No. Il Repository deve operare su oggetti di dominio e nascondere i dettagli di archiviazione. Un livello di accesso ai dati separato si occupa del mapping sullo schema del DB.
È lecito mescolare la logica di business all'interno della classe repository?
No. Questo violerebbe il Separation of Concerns: il Repository si occupa solo del recupero/salvataggio dei dati. La logica di business dovrebbe essere trasferita in servizi/oggetti di dominio.
Repository e DAO sono la stessa cosa?
Non esattamente. Il DAO è ortogonale al modello Repository, lavora a livello di tabelle e registrazioni, mentre il Repository lavora con oggetti di logica di business. Il Repository astrarre collezioni di entità di business, il DAO è più vicino all'infrastruttura.