Oblikovalski vzorci ponujajo preizkušene rešitve za resnične probleme, s katerimi se soočajo pri oblikovanju programske opreme. Vzorec repozitorija se uporablja za ločevanje poslovne logike in slojev dostopa do podatkov v vaši aplikaciji.
Sloj za dostop do podatkov običajno vsebuje posebno kodo za shranjevanje in metode za delovanje s podatki do in od shranjevanja podatkov. Sloj dostopa do podatkov, ki ga repozitorij povzame, je lahko ORM (tj. Entity Framework ali NHibernate), datoteka XML, spletna storitev itd. Lahko je celo zbirka stavkov SQL.
Pri uporabi vzorca zasnove repozitorija plast poslovne logike vaše aplikacije ne potrebuje nobenega znanja o tem, kako se obstojnost podatkov zgodi spodaj. V bistvu skladišče posreduje med domeno in sloji preslikave podatkov vaše aplikacije. Zagotavljal naj bi vam način, kako se podatki dejansko ohranjajo v plasti za shranjevanje podatkov.
Vzorec repozitorija je lahko koristen, če imate veliko entitet in imate veliko zapletenih poizvedb za delo s temi entitetami. Dodatna plast abstrakcije vam lahko v tem primeru pomaga odpraviti podvajanje logike poizvedb.
Generično repozitorij
Generično repozitorij je vrsta, ki vsebuje nabor generičnih metod za izvajanje operacij CRUD. Vendar je to le še en anti-vzorec in se z Entity Framework pogosto uporablja za abstrahiranje klicev na plast dostopa do podatkov. Po mojem mnenju je uporaba generičnega skladišča predaleč posploševanje. Slaba ideja je abstrahiranje klicev v Entity Framework z uporabo generičnega repozitorija.
Naj to pojasnim s primerom.
Naslednji seznam kod ponazarja generični repozitorij - vsebuje splošne metode za izvajanje osnovnih operacij CRUD.
javni vmesnik IRepository
{
IEnumerable GetAll ();
T GetByID (int id);
void Add (T item);
void Update (T element);
void Delete (T element);
}
Če želite ustvariti določeno repozitorij, bi morali nato implementirati generični vmesnik, kot je prikazano v spodnjem seznamu kod.
javni razred AuthorRepository: IRepository
{
// Izvedene metode vmesnika IRepository
}
Kot lahko vidite, bi morali za izdelavo katerega koli posebnega razreda repozitorija uporabiti vsako od metod vmesnika generičnega repozitorija. Glavna pomanjkljivost tega pristopa je, da bi morali za vsako entiteto ustvariti novo skladišče.
Tu je še ena pomanjkljivost tega pristopa: osnovni namen vzorca repozitorija je ločiti domensko plast od tega, kako plast dostopa do podatkov dejansko ohranja podatke. Tu je posodobljena različica razreda repozitorija, ki smo ga pravkar ustvarili.
javni razred AuthorRepository: IRepository
{
zasebni AuthorContext dbContext;
// Metode vmesnika IRepository
}
Kot lahko vidite v prej navedenem seznamu kod, AuthorRepository potrebuje primerek AuthorContext za izvajanje CRUD operacij, za katere je namenjen. Kje je torej ločitev? V idealnem primeru domena ne bi smela imeti nobenega znanja o logiki obstojnosti.
Dodaten sloj abstrakcije
Model domene in model trajnosti v aplikaciji imata popolnoma različni odgovornosti. Medtem ko prvi modeli vedejo, tj. Modelirajo resnične težave in rešitve teh težav, se drugi uporabljajo za modeliranje, kako so podatki aplikacije dejansko shranjeni v shrambi podatkov.
Namen vzorca repozitorija naj bi bil abstrahirati logiko obstojnosti in skriti notranje izvedbe ohranjanja podatkov. Delovanje skladišča mora biti dovolj izrazito in ne sme biti splošno. Ne morete imeti repozitorija, ki bi bil splošen in bi lahko vseboval operacije, ki ustrezajo kateremu koli scenariju. To postane nepotrebna abstrakcija in s tem generični vzorec repozitorija postane anti-vzorec. Vse predmete domene lahko modelirate na enak način. Generično repozitorij ne opredeljuje smiselne pogodbe in spet bi potrebovali določeno repozitorij, ki razširja vaše generično repozitorij in zagotavlja določen nabor operacij, ki so za to entiteto pomembne.
Zakaj zdaj, ko imate kar nekaj zrelih tehnologij za obstojnost podatkov (NHibernate, Entity Framework itd.), Zakaj sploh potrebujete to dodatno plast abstrakcije? Večina danes zrelih tehnologij ORM ima enake zmogljivosti. Ko poskušate uporabiti repozitorij, preprosto dodate dodaten sloj abstrakcije brez razloga. Kot primer boste morda potrebovali metode, kot je spodaj za vaš AuthorRepository.
FindAuthorById ()
FindAuthorByCountry ()
To se poslabša, saj imate vedno več metod in zapletenih iskanj - na koncu bi imeli skladišče, ki bi natančno preslikalo trajni pomnilniški sloj, ki se uporablja spodaj.
