Temat: Frameworki do ORM w PHP
Wojciech Małota:
Wojtek A.:
Natomiast realizują cel któremu miały służyć - przyspieszenie pracy. Nie przekonasz mnie że szybciej i prościej jest używać żywcem wysyłanymi zapytaniami SQL.
Nie tyle jest to "prostsze" co "wystarczająco proste" :)
Nie zgodze się z tym zarzutem - liczba tutorialów, szkoleń, ćwiczeń na studiach promuje raczej SQL niz ORM w zakresie tego co proste :-) Było kiedyś takie nawet powiedzenie "Dobry programista - to leniwy programista" w którym chodziło o to że dobry programista będzie tworzył rozwiązania które przyspieszają jego pracę. Takim rozwiązaniem jest moim zdaniem ORM.
Może tak jest w projekcie z 2 tabelami, ale w projekcie ze 130 powiązanymi tabelami o jakim mówisz robi się to problematyczne. Chodzi zwłaszcza o wygodne fetch-owanie wyników, ja nie muszę zadawać kolejnego zapytania, robię po prostu załóżmy getBooks() i zwraca mi obiekty powiązane do obiektu Library (przykład).
Ciekawe w ilu procentach przypadków chcesz otrzymać wszystkie książki powiązane z danym Library (przykład).
Nie musze otrzymywać wszystkich książek,moge dodac metodę FindBook(costam) w klasie dziedziczącej po tej wygenerewoanej i w jej treści przygotowac odpowiednie zapytanie (dekorator o którym już parę postów wyżej pisałem). Chodzi o zachowanie idei orm :-) Potem tego samego zapytana nie będe musiał pisać 10 kontrolkach (przeklejać)
Nie mam tutaj zamiaru demonizować ORMów - mają swoje pola zastosowań i dobrze. Natomiast obserwuję coś wręcz odwrotnego - demonizowanie zwykłego SQLa.
To wszystko zalezy od klasy systemu, czym będzie się zajmował, jakie będą jego zastosowania. Moim zdaniem elastyczniejsze jest używanie ORM (gdzie na przykład do wyszukiwania możesz zastosować kryteria), natomiast nie przeczę szybsze i wydajniesze jest stosowanie zapytań SQL i potem jechanie pętlą po wyniku w tablicy asocjacyjnej. Ale po to twórcy ORM wymyslili zapytania natywne, żeby w takich wypadkach móc zadawac pytania bezpośrednio w SQL - które zwrócą gotowe obiekty a nie tablice asocjacyjne.
Podejśc może być tyle ile ludzi, każde dobre jest na swój sposób. Nie myśl że demonizuje stosowanie czystego SQL. Tak samo jak Ty ja moge pomyśleć że demonizujesz ORM :-) Więc speirajmy sie nad wyższością świąt, tylko spójrzmy na temat dyskusji "Frameworki ORM w PHP", nie zbaczając z tematu :-)
пропозиції роботи
