Ohjelmointi

Suunnittelumallit, joita usein vältän: Varastokuvio

Suunnittelumallit tarjoavat todistettuja ratkaisuja reaalimaailman ohjelmistosuunnittelun ongelmiin. Tietovaraston mallia käytetään irrottamaan sovelluksen liiketoimintalogiikka ja tiedonsiirtokerrokset.

Tiedonsiirtokerros sisältää tyypillisesti tallennuskohtaisen koodin ja menetelmät tietojen käyttämiseksi tietovarastoon ja sieltä pois. Tietovaraston keräämä tietokerros voi olla ORM (eli Entity Framework tai NHibernate), XML-tiedosto, verkkopalvelu jne. Se voi olla jopa kokoelma SQL-käskyjä.

Kun käytetään arkiston suunnittelumallia, sovelluksesi liiketoimintalogiikan tasolla ei tarvitse olla tietoa siitä, miten tietojen pysyvyys tapahtuu alla. Pohjimmiltaan arkisto välittää sovelluksen toimialueen ja tietojen kartoitustasojen välillä. Sen odotetaan tarjoavan sinulle kapseloinnin siitä, miten tietoja todella säilytetään tietovarastokerroksessa.

Arkistomalli voi olla hyödyllinen, jos sinulla on monia entiteettejä ja sinulla on monia monimutkaisia ​​kyselyjä työskennellessäsi näiden entiteettien kanssa. Ylimääräinen abstraktiokerros voi tässä tapauksessa auttaa poistamaan kyselylogiikan päällekkäisyydet.

Yleinen arkisto

Yleinen arkisto on tyyppi, joka koostuu joukosta yleisiä menetelmiä CRUD-operaatioiden suorittamiseksi. Se on kuitenkin vain yksi anti-malli ja sitä käytetään usein Entity Frameworkin kanssa abstraktien puheluiden tiedonsiirtokerrokseen. Mielestäni yleisen arkiston käyttö on yleistämistä liian pitkälle. On huono idea abstrakti kutsu Entity Frameworkille yleisen arkiston avulla.

Haluan selittää tämän esimerkillä.

Seuraava koodiluettelo kuvaa yleistä arkistoa - se sisältää yleisiä menetelmiä CRUD-perustoimintojen suorittamiseksi.

julkinen käyttöliittymä IR-varasto

   {

ILukematon GetAll ();

T GetByID (int id);

void Lisää (T-kohde);

void Update (T-kohde);

void Poista (T-kohde);

   }

Tietyn tietovaraston luomiseksi sinun on sitten toteutettava yleinen käyttöliittymä alla olevan koodiluettelon mukaisesti.

public class AuthorRepository: IR-arkisto

   {

// IRepository-käyttöliittymän toteutetut menetelmät

   }

Kuten näette, minkä tahansa tietyn arkistoluokan luomiseksi joudut toteuttamaan kaikki yleisen arkistoliittymän menetelmät. Tämän lähestymistavan suurin haittapuoli on, että joudut luomaan uuden arkiston kullekin entiteetille.

Tässä on tämän lähestymistavan toinen haittapuoli: Arkistomallin perustarkoitus on erottaa verkkotunnuskerros siitä, kuinka datakäyttökerros tosiasiallisesti säilyttää tiedot. Tässä on päivitetty versio juuri luomastamme arkistoluokasta.

public class AuthorRepository: IRepository

   {

yksityinen AuthorContext dbContext;

// IRepository-käyttöliittymän menetelmät

   }

Kuten aiemmin annetusta koodiluettelosta näet, AuthorRepository tarvitsee AuthorContext-esiintymän suorittamaan CRUD-toiminnot, joihin se on tarkoitettu. Joten missä on irrotus? Ihannetapauksessa verkkotunnuskerroksella ei pitäisi olla tietoa pysyvyyslogiikasta.

Ylimääräinen abstraktiokerros

Verkkotunnusmallilla ja sovelluksen pysyvyysmallilla on selvästi erilaiset vastuut. Ensin mainittu mallintaa käyttäytymistä eli mallintaa tosielämän ongelmia ja ratkaisuja näihin ongelmiin, jälkimmäistä käytetään mallinnamaan, kuinka sovelluksen tiedot todella tallennetaan tietovarastoon.

Tietovarastomallin tarkoituksena on olla abstraktin pysyvyyslogiikan piilottaminen ja piilottaa sisäiset toteutukset siitä, miten tietoja säilytetään. Tietovaraston toiminnan tulisi olla riittävän ilmeistä eikä yleistä. Sinulla ei voi olla yleistä arkistoa ja sellaista, joka voi sisältää toimintoja, jotka sopivat mihin tahansa skenaarioon. Tästä tulee tarpeetonta abstraktiota, mikä tekee yleisestä arkistomallista anti-mallin. Voit mallintaa kaikki toimialueesi objektit samalla tavalla. Yleinen tietovarasto ei määritä merkityksellistä sopimusta, ja tarvitset jälleen tietyn tietovaraston, joka laajentaa yleistä tietovarastoa ja tarjoaa tietyt toiminnot, jotka ovat merkityksellisiä tälle tietylle yksikölle.

Nyt kun sinulla on muutama kypsä datan pysyvyystekniikka (NHibernate, Entity Framework jne.), Miksi tarvitset tätä ylimääräistä abstraktikerrosta? Suurimmalla osalla nykyään saatavilla olevista kypsästä ORM-tekniikasta on samat ominaisuudet. Kun yrität käyttää arkistoa, lisäät vain uuden kerroksen abstraktiota ilman mitään syytä. Saatat tarvita esimerkiksi seuraavia menetelmiä AuthorRepository-sovelluksellesi.

FindAuthorById ()

FindAuthorByCountry ()

Tämä pahenee, kun sinulla on enemmän ja enemmän menetelmiä ja monimutkaisia ​​hakuja - päädyt siihen, että sinulla on tietovarasto, joka kartoittaisi tiiviisti alla olevaa pysyvää varastokerrosta.