Îmi place cu adevărat modul de lucru 3 + 1 de a face lucruri.
Un nivel pentru UI, unul pentru logica de afaceri și pentru date persistente. Ultimul pe care-l spui? Obiecte și interfețe de domeniu. Acest lucru face posibila incarcarea oricarei sau a doua dintre nivelurile principale, plus domeniul "nivel", iar codul ar trebui sa functioneze.
Se bazează foarte mult pe injecții de dependență și Principiile inversării controlului .
Nivelul de date/persistență nu are decât două lucruri. Creează, citește, actualizează și șterge datele și le mută pe formatul obiectului de domeniu.
Nivelul UI face exact opusul. Se afișează și primește date într-un mod care utilizatorul poate referi la, și hărți care de ieșire/intrare și de formatul de domeniu de obiect.
Nivelul logicii de afaceri trebuie doar să știe un singur lucru. Lociga afacerii. Nu-i pasă de unde provin datele și nu-i pasă de locul în care se află nivelul de date. Știe că ar trebui să semnaleze un cont care a fost tocmai exagerat, cum să faci fizic acest lucru nu face parte din slujba lui într-adevăr.
Obiectele de domeniu în sine nu au nici o logică, sunt doar containere pentru trecerea datelor între niveluri. Aceasta înseamnă că puteți încărca obiectele de domeniu și interfețele fără a trebui să vă gândiți deloc la dependențe.
La sfârșitul zilei simt că am o bază de cod destul de clară, cu niveluri clar separate. Și cu unele interfețe stricte și clase bune de bază, cea mai mare parte a codificării este doar să spună software-ului ce să facă atunci când se întâmplă X. Cum ar trebui să fie.
Editați: Da, da. Acest lucru este valabil atât pentru linkurile LINQ, cât și pentru celelalte ORM-uri.