Leggevo alcuni articoli sui vantaggi della creazione di repository generici per una nuova app ( esempio ). L'idea sembra carina perché mi permette di usare lo stesso repository per fare diverse cose contemporaneamente per diversi tipi di entità:
IRepository repo = new EfRepository(); // Would normally pass through IOC into constructor
var c1 = new Country() { Name = "United States", CountryCode = "US" };
var c2 = new Country() { Name = "Canada", CountryCode = "CA" };
var c3 = new Country() { Name = "Mexico", CountryCode = "MX" };
var p1 = new Province() { Country = c1, Name = "Alabama", Abbreviation = "AL" };
var p2 = new Province() { Country = c1, Name = "Alaska", Abbreviation = "AK" };
var p3 = new Province() { Country = c2, Name = "Alberta", Abbreviation = "AB" };
repo.Add<Country>(c1);
repo.Add<Country>(c2);
repo.Add<Country>(c3);
repo.Add<Province>(p1);
repo.Add<Province>(p2);
repo.Add<Province>(p3);
repo.Save();
Tuttavia, il resto dell'implementazione del repository ha un strong affidamento su Linq:
IQueryable<T> Query();
IList<T> Find(Expression<Func<T,bool>> predicate);
T Get(Expression<Func<T,bool>> predicate);
T First(Expression<Func<T,bool>> predicate);
//... and so on
Questo modello di repository ha funzionato in modo fantastico per Entity Framework e praticamente ha offerto una mappatura 1 a 1 dei metodi disponibili su DbContext / DbSet. Ma dato il lento assorbimento di Linq su altre tecnologie di accesso ai dati al di fuori di Entity Framework, quale vantaggio offre oltre a lavorare direttamente con DbContext?
Ho tentato di scrivere una versione PetaPoco del repository, ma PetaPoco non supporta Linq Expressions, il che rende la creazione di un l'interfaccia IRepository generica è praticamente inutile a meno che non la usi solo per i metodi base GetAll, GetById, Add, Update, Delete e Save e la utilizzi come classe base. Quindi devi creare repository specifici con metodi specializzati per gestire tutte le clausole "where" che potrei passare in precedenza come predicato.
Il modello di Repository generico è utile per qualcosa al di fuori di Entity Framework? In caso contrario, perché qualcuno dovrebbe usarlo invece di lavorare direttamente con Entity Framework?
Il link originale non riflette il pattern che stavo usando nel mio codice di esempio. Ecco un ( link aggiornato ) .