Parca imi vine mai natural sa scriu un select..., dar au si orm-urile avantajele lor.
Acum am vazut ca articolul este din 2014. Intre timp s-au mai schimbat multe in vreo 5 ani. ORM-urile au devenit mai destepte, au difeite strategii de fetch a datelor (eager, lazy), performanta mai buna, api simplificat cu doar ce este relevant etc
Insa uneori magia este este coplesitoare. Ca nu vezi cum face acele lucruri. Si daca ceva nu merge trebuie sa sati sa cauti, sa inspectezi cu un profiler sa vezi ce query se genereaza, sa il testezi poate.
ORM-ul il consider destul de greoi si complicat. Deseori pot scrie query-ul de mana mult mai rapid decat imi ia sa gasesc hack-ul pentru ORM.
Desigur, la aplicatii simple unde citesti/scrii date din/in cateva tabele e ok. Dar cand ai tabele cu serioase probleme de legatura, de genul tabele parinte-fiu unde trebuie pastrata legatura Parinte.id = Fiu.id (in loc de Fiu.parinte_id), eh, e mai greu cu ORM-uri.
Chei primare indentice/refolosite în mai multe table e o practică îndoielnică oricum, lăsând ORM-ul la o parte. Pe de altă cu Doctrine poți gestiona o situație de genul destul de ușor.
În ulitmii ani eu am lucrat foarte mult cu ORM (Doctrine) și deși nu este vreuo unealtă fermecată care m-a scăpat de toate problemele (ba chiar a introdus unele noi la un moment dat), consider că aduce mult mai multe plusuri decat minusuri.
Fiind o implementare Data Mapper pattern, Doctrine m-a scapt în primul rând de probeleme cu validarea datelor și/sau asocierile din formulare (în contextul unei aplicații Symfony).
Tot timpul asta am creat și destul de metode specifice prin cod în care am folosit SQL nativ (pentru interogari complexe) sau pentru a returna valori concrete, rapid, pentru ca nu aveam nevoie de întreg obiectul (sau relațiile lui).
PS: Să zici ca poți folosi un ORM fără să cunoști și inteleg elementele de bază ale serverului de baze date folosit e ca și cum ai zice că poți să folosești un framework fără să întelegi limbajul în care e scris. Nu cred că are vreun sens.
PPS: Chiar dacă ai un ciocan mare (ORM-ul), nu înseamnă ca tot ce în jur sunt cuie.
Daca toti avem scrise query-uri de mana prin aplicatii, ce rost are un ‘ceva’ extra? Doar pentru niste SELECT-uri mai frumoase?
Problema nu e la JOIN-uri sau la validarea datelor. Problema e cand ai de scris query-uri cu CASE, cu prioritizari, ca alegere manuala a indecsilor, cu ON DUPLICATE KEY, etc.
Păi cine de obligă să folosești un framework? Și framework-ul, ca și ORM-ul vine cu limitările lui (și avantaje bineînteles).
Ah, framework-urile te ajută să dezvolți mai rapid. Pai ORM-ul este în general parte integrantă din acest “mai rapid”. De asta toate framework-urile au unul.
Dacă ai interogări complexe, le scrii de mână și gata, dar în general, un proiect va avea câteva interogări cu CASE (sau funcții GIS sau alte chestii specifice) și mult mai multe interogari generice, care pot fi satisfăcute de un ORM.
Și framework-ul, ca și ORM-ul vine cu limitările lui (și avantaje bineînteles).
(yep, it’s still a thing!)