Programmēšana

Dizaina modeļi, no kuriem es bieži izvairos: Krātuves modelis

Dizaina modeļi nodrošina pārbaudītus risinājumus reālās pasaules problēmām, ar kurām saskaras programmatūras dizains. Krātuves modeli izmanto, lai atdalītu biznesa loģiku un datu piekļuves slāņus jūsu lietojumprogrammā.

Datu piekļuves slānis parasti satur glabāšanas specifisku kodu un metodes, kā darboties ar datiem uz un no datu krātuves. Datu piekļuves slānis, ko repozitorijs iegūst, var būt ORM (t.i., Entity Framework vai NHibernate), XML fails, tīmekļa pakalpojums utt. Tas var būt pat SQL priekšrakstu kolekcija.

Izmantojot krātuves noformējuma modeli, jūsu lietojumprogrammas biznesa loģikas slānim nav nepieciešamas zināšanas par to, kā zemāk notiek datu noturība. Būtībā krātuve ir starpnieks starp jūsu lietojumprogrammas domēnu un datu kartēšanas slāņiem. Paredzams, ka tas jums nodrošinās veidu, kā dati faktiski tiek saglabāti datu glabāšanas slānī.

Krātuves modelis var būt noderīgs, ja jums ir daudz entītiju un jums ir daudz sarežģītu vaicājumu, lai strādātu ar šīm entītijām. Šajā gadījumā papildu abstrakcijas slānis var palīdzēt novērst vaicājumu loģikas dublēšanos.

Vispārīgais repozitorijs

Vispārējs repozitorijs ir tips, kas sastāv no vispārēju metožu kopuma CRUD darbību veikšanai. Tomēr tas ir tikai vēl viens anti modelis, un to bieži lieto kopā ar Entity Framework, lai abstrakti izsauktu zvanus uz datu piekļuves slāni. Manuprāt, vispārīga repozitorija izmantošana ir pārāk tālu vispārināšana. Slikta ideja ir abstrakti izsaukumi uz Entity Framework, izmantojot vispārīgu krātuvi.

Ļaujiet man to paskaidrot ar piemēru.

Šis kodu saraksts ilustrē vispārēju repozitoriju - tajā ir vispārīgas metodes CRUD pamata darbību veikšanai.

publiskā saskarne IR krātuve

   {

ISkaitāmie GetAll ();

T GetByID (int id);

void Pievienot (T vienums);

anulēt atjauninājumu (T vienums);

void Dzēst (T vienums);

   }

Lai izveidotu konkrētu repozitoriju, jums jāievieš vispārējā saskarne, kā parādīts zemāk esošajā kodu sarakstā.

public class Autora krātuve: IR krātuve

   {

// IRepository saskarnes ieviestās metodes

   }

Kā redzat, lai izveidotu kādu konkrētu repozitorija klasi, jums būs jāievieš katra no vispārējā repozitorija saskarnes metodēm. Šīs pieejas galvenais trūkums ir tas, ka jums vajadzētu izveidot jaunu repozitoriju katrai entītijai.

Šeit ir vēl viens šīs pieejas trūkums: krātuves modeļa pamatmērķis ir atdalīt jūsu domēna slāni no tā, kā datus faktiski saglabā datu piekļuves slānis. Šeit ir tikko izveidotās krātuves klases atjauninātā versija.

public class Autora krātuve: IR krātuve

   {

privāts AuthorContext dbContext;

// IRepository saskarnes metodes

   }

Kā redzat iepriekš norādītajā kodu sarakstā, AuthorRepository ir nepieciešama AuthorContext instance, lai veiktu CRUD operācijas, kurām tā ir paredzēta. Tātad, kur tad ir atsaistīšana? Ideālā gadījumā domēna slānim nevajadzētu būt zināšanām par noturības loģiku.

Papildu abstrakcijas slānis

Domēna modelim un pastāvības modelim lietojumprogrammā ir skaidri atšķirīgi pienākumi. Kamēr pirmais modelē uzvedību, t.i., modelē reālās dzīves problēmas un šo problēmu risinājumus, otro izmanto, lai modelētu, kā lietojumprogrammas dati faktiski tiek glabāti datu krātuvē.

Repozitorija modeļa nolūks ir abstraktēt noturības loģiku un paslēpt datu saglabāšanas iekšējās ieviešanas iespējas. Repozitorija darbībām jābūt pietiekami izteiksmīgām, nevis vispārīgām. Jums nevar būt glabātava, kas ir vispārēja un kurā var ietilpt darbības, kas der jebkuram scenārijam. Tas kļūst par nevajadzīgu abstrakciju un līdz ar to vispārējo krātuves modeli padara par anti-modeli. Visus savus domēna objektus varat modelēt vienādi. Vispārējs repozitorijs nenosaka jēgpilnu līgumu, un jums atkal būtu nepieciešams īpašs repozitorijs, kas paplašina jūsu vispārīgo repozitoriju un nodrošina konkrētu darbību kopumu, kas ir nozīmīgs šai konkrētajai entītijai.

Tagad, kad jums ir diezgan daudz nobriedušu datu noturības tehnoloģiju (NHibernate, Entity Framework utt.), Kāpēc jums tomēr ir vajadzīgs šis papildu abstrakcijas slānis? Lielākajai daļai mūsdienās pieejamo nobriedušo ORM tehnoloģiju ir tādas pašas iespējas. Mēģinot izmantot repozitoriju, jūs vienkārši pievienojat papildu abstrakcijas slāni bez jebkāda iemesla. Piemēram, jums var būt nepieciešamas tādas metodes kā autorRepository.

FindAuthorById ()

FindAuthorByCountry ()

Tas kļūst vēl sliktāk, jo jums ir arvien vairāk metožu un sarežģītu meklējumu - galu galā jums būtu repozitorijs, kas precīzi attēlotu zem tā esošo pastāvīgo glabāšanas slāni.

$config[zx-auto] not found$config[zx-overlay] not found