Best Practices pentru stratul de date

În aplicațiile în care utilizăm NHibernate, răspunsul devine "undeva între", prin faptul că, în timp ce definițiile de mapare xml (care specifică ce tabel aparține acelui obiect și ale căror coloane aparțin câmpului etc.) sunt clar în nivelul de obiect de activitate .

Acestea sunt transmise unui manager de sesiuni de date generice care nu cunoaște niciunul dintre obiectele afacerii; singura cerință este ca obiectele de afaceri care i-au fost transmise pentru CRUD trebuie să aibă un fișier de cartografiere.

O carte excelentă pe care o am, care acoperă acest subiect, este Modele de acces la date , de Clifton Nock. Are multe explicații și idei bune despre cum să decuplați stratul de afacere de stratul de persistență. Chiar ar trebui să încercați. Este una dintre cărțile mele preferate.

Un truc pe care l-am găsit la îndemână este ca nivelul meu de date să fie "agnostic de colectare". Asta este, ori de câte ori doresc să revin o listă de obiecte din stratul meu de date, primesc apelantului să treacă în listă. Deci, în loc de asta:

public IList GetFoosById(int id) { ... }

Eu fac asta:

public void GetFoosById(IList foos, int id) { ... }

This lets me pass in a plain old List if that's all I need, or a more intelligent implementation of IList (like ObservableCollection) if I plan to bind to it from the UI. This technique also lets me return stuff from the method like a ValidationResult containing an error message if one occurred.

Aceasta inseamna inca ca stratul meu de date stie despre definitiile obiectului meu, dar imi ofera un grad suplimentar de flexibilitate.

Check out Linq la SQL, dacă aș fi creat o nouă aplicație acum, aș lua în considerare bazându-mă pe un întreg strat de date bazat pe Linq.

În afară de asta, cred că este o practică bună să dezactivați datele și logica cât mai mult posibil, dar acest lucru nu este întotdeauna practic. O separare pură între logică și accesul la date face ca îmbinările și optimizările să fie dificile, ceea ce face ca Linq să fie atât de puternic.

Depinde într-adevăr de viziunea ta asupra lumii - am fost în tabăra necondiționată. DAL a fost doar acolo pentru a furniza date către sfârșitul povestii BAL.

Cu tehnologiile emergente cum ar fi Linq to SQL și Entity Framework devin un pic mai populare, atunci linia dintre DAL și BAL a fost încețoșată. În L2S, în special, DAL-ul dvs. este destul de strâns legat de obiectele Business, deoarece modelul obiect are o mapare 1-1 în câmpul bazei de date.

Ca orice în dezvoltarea de software nu există nici un răspuns corect sau greșit. Trebuie să înțelegeți cerințele și cerințele viitoare și să lucrați de acolo. N-aș mai folosi un Ferrari pe raliul Dakhar, așa cum aș fi un Range Rover pe o zi de pistă.

Puteți avea și amândouă. Lăsați stratul de date să nu știe de obiectele dvs. de afaceri și să-l facă capabil să lucreze cu mai mult de un tip de surse de date. Dacă furnizați o interfață comună (sau o clasă abstractă) pentru a interacționa cu datele, puteți avea implementări diferite pentru fiecare tip de sursă de date. Modelul de fabrică merge bine aici.

Postare veche, dar căutarea unor informații similare am întâlnit acest care explică frumos.

Jeffrey Palermo a scris un post bun despre asta. El a numit-o Arhitectura de ceapă .