Best Practices pentru stratul de date

Sunt în mijlocul unei "discuții" cu un coleg despre cea mai bună modalitate de a implementa stratul de date într-o nouă aplicație.

Un punct de vedere este că stratul de date trebuie să fie conștient de obiectele afacerii (propriile clase care reprezintă o entitate) și să poată lucra cu acest obiect nativ.

Punctul opus este acela că stratul de date trebuie să fie obiect-agnostic și să se ocupe pur și simplu de tipurile de date simple (șiruri, răniri, date etc.)

Văd că ambele abordări pot fi valabile, dar punctul meu de vedere este acela că eu prefer cel dintâi. În acest fel, dacă mediul de stocare a datelor se modifică, stratul de afaceri nu trebuie (neapărat) să se schimbe pentru a se adapta la noul strat de date. Ar fi așadar un lucru banal să schimbi dintr-un magazin de date SQL într-un magazin serializat de sisteme de fișiere xml.

Punctul de vedere al colegului meu este că stratul de date nu ar trebui să știe despre definițiile obiectului și că, atâta timp cât datele sunt transmise corespunzător, este suficient.

Acum, știu că aceasta este una dintre acele întrebări care are potențialul de a începe un război religios, dar aș aprecia orice feedback din partea comunității cu privire la modul în care abordați astfel de lucruri.

TIA

0
fr hi bn

8 răspunsuri

Î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.

0
adăugat

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.

0
adăugat

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.

0
adăugat

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.

0
adăugat

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ă.

0
adăugat
Sunt total de acord. Designul straturilor de acces la date, etc, devine destul de neclar. Întrucât aș alege întotdeauna să vă separați logica de afaceri de straturile de prezentare. MVC model FTW ;-)
adăugat autor Tobias N. Sasse, sursa

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.

0
adăugat

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

0
adăugat

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

0
adăugat