O intrebare care revine deseori este ce folosim :Un ORM ( L2S, EF, NHibernate, custom code) sau ADO.NET direct( procedura stocata, trimitere de query la BD ) ?
Criteriile pe care le folosesc sunt :
- timpul de dezvoltare – timpul pe care il aloc eu, ca dezvoltator, ca sa scriu codul
- performanta – timpul in care codul meu se executa ca sa faca obtina rezultatul dorit. Inclusiv cit imi ia timpul de incarcare al datelor din BD.
Tinind seama de aceste criterii, pentru mine exista un raspuns clar : depinde.
Enumar cazurile mele principale :
- Utilizez un ORM ca sa ma scape de bataia de cap cu filtering/paging/sorting. Daca ati scrie un query de mina cu asta sau o PS – ar fi destul de greu ( oribil ca timp de dezvoltare)
- Sa zicem ca vrem sa modificam toate contractele pentru clientii care au > 4 ani si le dam inca o luna gratis. Daca am face asta cu un ORM ar insemna un cursor( oribil ca performanta) – asa ca mai bine facem un ADO.NET direct “ update table …” – cu procedura stocata sau direct ca text
- Daca vreau sa fac update la o un singur cimp ( de exemplu, daca vreau in incrementez numarul de download pentru un fisier) este absurd(oribil ca performanta: timp de incarcare) sa incarc row-ul de fisier cu ( id, , nume, cale, numarul de download si alte date) ca sa obtin incrementez doar numarul de download si sa salvez inapoi in BD. Mai bine fac un update rapid cu ADO.NET direct . ( Oh, daca sunt puturos , chiar folosesc ORM)
- Daca fac update pe mai multe cimpuri, e absurd ( oribil ca timp de dezvoltare) sa scriu un update pentru toate cimpurile. Mai bine folosesc ORM-ul.
Concluzia: folositi right tool for the right job.
Adaugare: Tudor Turcu , http://tudorturcu.wordpress.com/ adauga ca ADO.NET se mai foloseste la reporting si la optimizari de SP. -vezi comentariu.
PS :Mai stiti si alte cazuri ?
Orice O/RM decent permite maparea unei metode, respectiva a operatiilor de CRUD la stored procedures atunci cand se doreste asta pe motove de performanta sau din motive de DB Admin incapatanat..
Motivul de baza in a folosi un O/RM, inafara de cel de productivitate, vine din cazurile in care domain model-ul difera in mod substantial de modelul relational implementat in DB (si pentru aplicatiile non-triviale, e de asteptat sa difere, mai ales cand se foloseste domain-driven design).
Al doilea motiv fundamental: descrierea query-urilor si operatiilor de update in termeni de domain model, strongly typed (deci usor de refactorizat), fara a trebui schimat codul C# in 20 de locuri cand se redenumeste un field in DB.
Cazurile in care trebuie apelat la “raw” ADO.NET sunt tot mai rare – multe O/RM-uri mature (si nu ma refer la EF
), permit definirea de operatii de update (cazurile 2 si 3 de mai sus), fara a fi nevoie de incarcarea row-urilor din DB, strongly-typed si fara a folosi stored procedures.
Cazurile cand e nevoie musai de stored procedures (insa mapate tot cu O/RM-ul):
– query-uri sau update-uri care trebuie optimizate musai si pentru care se folosesc features specifice database server-ului respectiv sau care nu sunt suportate de O/RM, gen CTE (common table expressions) pe SQL Server (foarte folosit pentru a optimiza unele query-uri)
– agregari complexe care sunt greoi de descris in LINQ sau in O/RM-ul respectiv
– batch procession/batch updates care nu sunt triviale
Nu in ultimul rand, O/RM cam iese din discutie cand e vorba de reporting (unde chiar daca ar fi posibil un ORM, maparea intre ce se afiseaza si ce e returnat de engine-ul de reporting e de obicet 1-la-1, deci nu se justifica overheadul, iar toolurile specializate isi fac mult mai bine treaba).
Sunt sigur ca si tu stii de toate cazurile astea, da’ poate mai citeste si altcineva postul..
Multumesc Tudor!
Manual mapping invelit in Repository pattern
Andrei – chiar m-ai lasat ginditor. Poti detalia?
folosit direct SqlDataReader, mapare “manuala” intre indexer-ul SqlDataReader-ului si proprietatile obiectului rezultat, aplicat insa Repository pattern (o interfata ce strange operatiile posibile).