Dizaino modeliai teikia patikrintus sprendimus realioms problemoms, su kuriomis susiduriama kuriant programinę įrangą. Saugyklos modelis naudojamas verslo logikai ir duomenų prieigos sluoksniams atsieti jūsų programoje.
Duomenų prieigos sluoksnyje paprastai yra specifinis saugyklos kodas ir metodai, kaip valdyti duomenis į duomenų saugyklą ir iš jos. Duomenų prieigos sluoksnis, kurį talpina saugykla, gali būti ORM (t. Y. „Entity Framework“ arba „NHibernate“), XML failas, žiniatinklio paslauga ir kt. Tai gali būti net SQL sakinių rinkinys.
Naudojant saugyklos dizaino modelį, jūsų programos verslo logikos sluoksniui nereikia turėti jokių žinių apie tai, kaip vyksta duomenų išlikimas. Iš esmės saugykla tarpininkauja tarp jūsų domeno ir duomenų susiejimo sluoksnių. Manoma, kad tai padės jums iš tikrųjų išsaugoti duomenis duomenų saugojimo sluoksnyje.
Saugyklos modelis gali būti naudingas, kai turite daug objektų ir turite daug sudėtingų užklausų, kaip dirbti su tais objektais. Tokiu atveju papildomas abstrakcijos sluoksnis gali padėti išvengti užklausos logikos dubliavimo.
Bendroji saugykla
Bendroji saugykla yra tipas, kurį sudaro bendrųjų metodų rinkinys CRUD operacijoms atlikti. Tačiau tai tik dar vienas anti modelis ir dažnai naudojamas su „Entity Framework“, norint abstrakčiai iškviesti skambučius į duomenų prieigos sluoksnį. Mano nuomone, bendrosios talpyklos naudojimas yra per didelis apibendrinimas. Bloga idėja yra abstrakti skambučiai į „Entity Framework“, naudojant bendrą saugyklą.
Leiskite man tai paaiškinti pavyzdžiu.
Šis kodų sąrašas iliustruoja bendrąją saugyklą - joje yra bendri metodai pagrindinėms CRUD operacijoms atlikti.
viešoji sąsaja IR saugykla
{
ISuskaičiuojamas „GetAll“ ();
T „GetByID“ (int id);
negaliojantis Pridėti (T elementas);
negaliojantis atnaujinimas (T elementas);
void Delete (T elementas);
}
Jei norite sukurti konkrečią saugyklą, turėsite įdiegti bendrą sąsają, kaip parodyta žemiau esančiame kodų sąraše.
public class AuthorRepository: IR saugykla
{
// Įdiegti „IRepository“ sąsajos metodai
}
Kaip matote, norint sukurti bet kurią konkrečią saugyklos klasę, turėsite įdiegti kiekvieną iš bendrosios saugyklos sąsajos metodų. Pagrindinis šio požiūrio trūkumas yra tas, kad turėtumėte sukurti naują kiekvieno objekto saugyklą.
Štai dar vienas šio požiūrio trūkumas: pagrindinis saugyklos modelio tikslas yra atsieti domeno sluoksnį nuo to, kaip duomenis iš tikrųjų išlaiko duomenų prieigos sluoksnis. Štai atnaujinta ką tik sukurtos saugyklos klasės versija.
public class AuthorRepository: IR saugykla
{
privatus AuthorContext dbContext;
// „IRepository“ sąsajos metodai
}
Kaip matote anksčiau pateiktame kodų sąraše, „AuthorRepository“ reikia „AuthorContext“ egzemplioriaus, kad jis galėtų atlikti CRUD operacijas, kurioms ji skirta. Taigi, kur tada atsiejimas? Idealiu atveju domeno sluoksnis neturėtų žinoti apie atkaklumo logiką.
Papildomas abstrakcijos sluoksnis
Domeno modelis ir patvarumo modelis programoje turi aiškiai skirtingas pareigas. Pirmasis modeliuoja elgesį, t. Y. Modeliuoja realaus gyvenimo problemas ir tų problemų sprendimus, antrasis naudojamas modeliuoti, kaip programos duomenys iš tikrųjų saugomi duomenų saugykloje.
Saugyklos modelio tikslas turėtų būti atkartoti atkaklumo logiką ir paslėpti vidinius duomenų išsaugojimo būdus. Saugyklos operacijos turėtų būti pakankamai išraiškingos ir ne bendros. Negalite turėti bendros saugyklos, kurioje būtų operacijų, tinkančių bet kokiems scenarijams. Tai tampa nereikalinga abstrakcija ir todėl bendrasis saugyklos modelis tampa antimustriniu. Visus savo domeno objektus galite modeliuoti vienodai. Bendroji saugykla neapibrėžia prasmingos sutarties, todėl jums vėl reikės konkrečios saugyklos, kuri išplėstų jūsų bendrąją saugyklą ir pateiktų konkrečių operacijų rinkinį, kuris yra reikšmingas tam konkrečiam subjektui.
Dabar, kai turite nemažai brandžių duomenų išlikimo technologijų („NHibernate“, „Entity Framework“ ir kt.), Kodėl jums vis tiek reikalingas šis papildomas abstrakcijos sluoksnis? Dauguma šiuolaikinių ORM technologijų, kurios yra prieinamos šiandien, turi tas pačias galimybes. Bandydami naudoti saugyklą, jūs tiesiog pridėkite papildomą abstrakcijos sluoksnį be jokios priežasties. Pavyzdžiui, „AuthorRepository“ jums gali prireikti tokių metodų, kaip nurodyta toliau.
„FindAuthorById“ ()
„FindAuthorByCountry“ ()
Tai dar labiau pablogėja, kai turite vis daugiau metodų ir sudėtingų paieškų - galų gale turėtumėte saugyklą, kuri tiksliai susietų su po juo naudojamu nuolatiniu saugojimo sluoksniu.
