ActiveRecord, ORM |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
ActiveRecord, ORM |
14.05.2007, 18:00:11
Post
#21
|
|
Grupa: Zarejestrowani Postów: 148 Pomógł: 0 Dołączył: 16.06.2003 Ostrzeżenie: (0%) |
Trzecia sprawa to to, że początkowy zysk w postaci szybszego kodowania jest opłacony przez mniejszą przejrzystość kodu w przyszłości. No cos ty - to wyobraz sobie co sie dzieje w momencie kiedy masz aplikacje napisana z palca - i masz jakies 200 roznych SQL query - i klient jest bardzo przesądny i naprzyklad nie podoba mu sie pole czarny_kot w bazie danych - musisz zmienic 200 zapytań - w propelu jeden tag XML i działasz... pozatym myślę ze idea AR i ORM jest inna niż wszyscy myśla tu - klasy ORM sa po to aby juz enkapsulować jakąs logike biznesowa - powstały po to aby zintegrowac warste funkcjonalności biznesowych z dotyczacych tych danych. obiekt ORM jest po to zeby zdefiniowac także akcje jakie z obiektem sa powiazane, jest gdzies pomiedzy warstwa danych a biznesowa - natomiast nie ma watpliwosci ze AR jest tylko do ujednolicenia dostepu do bazy - na mniejszym stopniu abstrakcji niż ORM ale znacznie wiekszym niz bawienie sie w zapytania... -------------------- -=Yacho=-
nospor -> trzymaj sie i nie dajcie sie ! |
|
|
14.05.2007, 21:27:35
Post
#22
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
Yacho nie dość, że cytujesz moją wypowiedź sprzed 2 miesięcy, to jeszcze była ona na temat AR a nie ORM
Tak jak tam pisałem odnosiłem się do AR na przykładzie ZF, z którym miałem okazję spędzić trochę czasu. Problem jak się tu pojawił to, to że w momencie zmiany nazwy pola w tabeli musiałbym poprawić wszystkie odwołania, które korzystały z tej tabeli - także akurat Twój przykład tutaj nie za bardzo był trafny. Pod wpływem tego wątku zainteresowałem się ORM (konkretnie Propelem) o czym też zresztą pisałem już w tym wątku Powiem szczerze, że jestem pozytywnie zaskoczony tym rozwiązaniem - nie myślałem, że w PHP uda się takie coś popełnić. Właśnie kończę pierwszy projekt z wykorzystaniem Propel'a i to jest coś czego mi od dawna brakowało. Co do ORM to nie podoba mi się przekonanie, że są one bez sensu bo przy skomplikowanych zapytaniach wykonują nieoptymalne operacje i są be. Wiadomo, że jeśli robisz joina po wielu tabelach, czy wykonujesz jakieś skomplikowane zapytanie, to automatix nie jest najlepszym wyjściem - ORM ułatwia korzystanie z bazy, ale nie zdejmuje z programisty konieczności myślenie i optymalizacji. Po prostu są rzeczy, które można zostawić Propelowi do zrobienia i są takie w których trzeba mu trochę pomóc. W propelu podoba mi się to, że przewidziano możliwość własnego konstruowania zapytań czy dodawania logiki do klasy. Programowanie z Propelem to jest po prostu bajka. |
|
|
23.05.2007, 17:57:58
Post
#23
|
|
Grupa: Zarejestrowani Postów: 237 Pomógł: 1 Dołączył: 8.02.2007 Ostrzeżenie: (10%) |
Myślę sobie teraz o ORM...
Według mnie jest to utrudnianie sobie życia. Chyba lepiej poznać SQL niż uczyć się metod, które działają tak samo jak polecenia w SQL-u... Argument? Mamy jakieś złożone zapytanie, przy pomocy takiego ActiveRecords tego nie zrobimy. No i co? Musimy się uczyć SQL-a lub szukać po internecie jak coś zrobić. A nie lepiej od razu poznać go? Aplikacja działa szybciej, bo nie odpala iluś tam metod zanim wykona zapytanie. IMHO ORM jest ułatwieniem dla początkujących Ten post edytował Sokal 23.05.2007, 17:58:15 -------------------- Jabber/E-Mail: dominiksokal[at]gmail.com | GG: #3795571
|
|
|
23.05.2007, 18:05:32
Post
#24
|
|
Grupa: Zarejestrowani Postów: 493 Pomógł: 0 Dołączył: 14.06.2003 Skąd: Tomaszów Lubelski/Rzeszów Ostrzeżenie: (0%) |
Jestes w błedzie Misiu (a moze pingwinku;) )
Złozone zapytania? Ich raczej czesto nie piszemy. -------------------- |
|
|
23.05.2007, 18:11:20
Post
#25
|
|
Grupa: Zarejestrowani Postów: 237 Pomógł: 1 Dołączył: 8.02.2007 Ostrzeżenie: (10%) |
A co powiesz na to, że piszesz jakąś super złożoną aplikację. W bazie trudno się połapać a złożone zapytania to są co drugą linijkę w kodzie.
Nie zrobisz tego przy użyciu, np. activerecords. Co prawda masz tam metodę query(), ale jak jest activerecords to po co taka metoda? Skoro: złożone zapytania => "Ich raczej czesto nie piszemy."... Według mnie lepiej korzystać np. z PDO // I jeszcze jeden argument: Przez ORM kod aplikacji się wydłuża Ten post edytował Sokal 23.05.2007, 18:12:27 -------------------- Jabber/E-Mail: dominiksokal[at]gmail.com | GG: #3795571
|
|
|
23.05.2007, 19:22:15
Post
#26
|
|
Administrator PHPedia.pl Grupa: Developerzy Postów: 1 102 Pomógł: 2 Dołączył: 14.09.2003 Ostrzeżenie: (0%) |
Cytat // I jeszcze jeden argument: Przez ORM kod aplikacji się wydłuża kod? no prosze.
jest dluzsze od selecta w sqlu? poza tym, orm sprawia kod bardziej czytelnym co do zlozonych zapytan, ja czesto ich nie uzywam, czasem zdarzaja sie join na dwoch poziomach, ktorych niestety propel jeszcze nie obsluguje. ale miejmy nadzieje ze propel 2.0 bedzie niebawem -------------------- |
|
|
23.05.2007, 19:31:18
Post
#27
|
|
Grupa: Zarejestrowani Postów: 493 Pomógł: 0 Dołączył: 14.06.2003 Skąd: Tomaszów Lubelski/Rzeszów Ostrzeżenie: (0%) |
No to zaczynamy:
Sam AR moze i jest trudniejszy i bez sensu przy PDO, ale juz odpowiednio zbudowany ORM to juz inna bajka. Przyklady beda sie opierac na moim skrypcie. Dodatko do pelni szczescia potrzebne jest np. PHPIDE aby ladnie podpowiadalo metody obiektu Zacznijmy od tego ze strukture bazy danych definiujemy podobnie jak w propelu w xmlu. Na podstawie tego sa generowane odpowiednie klasy modelu. Najpierw "tworzymy" zapytanie
Mamy juz pobrane dane do $aNews. Wpisujujac $aNews-> otrzymujemy z podpowiedzi cala liste dostepych kolumn. Bo kazda kolumna ma metode getKolumna(). Dodatkowo dla dolaczonych tablel najpierw $aNews->joinJakasKolumna()->jakasKolumna() Oczywiscie wszystkie metody podpowiada nam eclipse. Tak by wygladala sprawa z pobieraniem danych. Przejdzmy teraz moze do ich dodawania No i znowu tutaj kazda metoda odpowiada kolumnie w bazie danych. Dodatkowo mamy tutaj filtrowanie danych, tak wiec nie wstawimy jakiegos stringa do kolumny ktora oczekuja liczbe. I powiedz mi ze to jest niewygodne to cie normalnie nie wiem co -------------------- |
|
|
23.05.2007, 20:04:59
Post
#28
|
|
Grupa: Zarejestrowani Postów: 237 Pomógł: 1 Dołączył: 8.02.2007 Ostrzeżenie: (10%) |
Dla mnie to zawsze będzie niewygnodne, co z tego, że podpowiada mi składnie...
Więcej czasu zabiera wykonywanie zapytań -------------------- Jabber/E-Mail: dominiksokal[at]gmail.com | GG: #3795571
|
|
|
23.05.2007, 20:07:08
Post
#29
|
|
Grupa: Zarejestrowani Postów: 493 Pomógł: 0 Dołączył: 14.06.2003 Skąd: Tomaszów Lubelski/Rzeszów Ostrzeżenie: (0%) |
Co z tego? Np. to ze nie musisz pamietac nazw wszystkich tabel ani kolumn w bazie danych. To ze masz wieksza kontrole. To ze jest wygdniej Dorosniesz to zrozumiesz (joke)
-------------------- |
|
|
24.05.2007, 00:19:43
Post
#30
|
|
Grupa: Zarejestrowani Postów: 24 Pomógł: 0 Dołączył: 1.05.2006 Skąd: Leżajsk\Kraków Ostrzeżenie: (0%) |
Witam
Ot dorzuce swoje 3 grosze.... Osobiście używam PEAR DB_DataObject... Bardzo mnie sie podoba mialem troch problemów tyczącyc sie pierwszegoo uruchomienia i pierwszego utworzenia klas odwzorowujacych tabele.... Ale teraz wszystko idzie gładko..... Wszystko tworzy sie automatycznie pozniej tylko wykorzystuje klasy... Do tej pory nie zauważylem nadmiaru zapytań chciaż czasem jestem zbyt wyrozumiały wobec ilośici zapytań generowanych przez moj kod... Wczećniej uzywałem ADOdb i teraz wydaje mnie sie ze teraz ograniczyłem liczbe zapytań.... Kod też staje sie bardziej przejżysty ot chodźby pobranie usera:
i w objekcie user mam odrazu wszystko, warunki nie ma problemu:
cala struktura klasy na podstawie bazy jest przygotowywana z pommocą skryptu.... wiec zero pracy do wykonania... No chyba że chcemy jekies specjalne warunki przy dodawaniu do bazy... validatory nie napisza sie same.... wydaje mnie sie proste i przyjemne... Ale moze to tylko przyzwyczajenie.... Pozdrawiam -------------------- Errare humanum est
|
|
|
24.05.2007, 11:52:32
Post
#31
|
|
Grupa: Przyjaciele php.pl Postów: 7 494 Pomógł: 302 Dołączył: 31.03.2004 Ostrzeżenie: (0%) |
~Sokal a dlaczego uważasz że ORM jest dla osób nie znających SQL'a?
Tak się składa że jest dokładnie odwrotnie. Nie podejdziesz do żadnego ORM'a nie mając solidnych podstaw i wiedzy o SQL. "IMHO ORM jest ułatwieniem dla początkujących " - to Twoja opinia. A praktyka pokazuje że żaden większy bądź duży projekt nie jest pisany bez ORM'a Już pomijam PHP, w Java na przykład większość aplikacji śmiga na Hibernate. |
|
|
24.05.2007, 12:04:35
Post
#32
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) |
Dla mnie to zawsze będzie niewygnodne, co z tego, że podpowiada mi składnie... Więcej czasu zabiera wykonywanie zapytań To po cholerę tu siedzisz, pytam? To forum to niby PRO więc się nie zachowuj jak dziecko i nie strzelaj fochów, że coś Ci się nie podoba i basta. Po cholerę wcinałeś się do tego wątku, tylko po to, żeby pokazać swoje wstecznictwo i ciemnotę? Jeśli nie masz więcej argumentów przeciw to, proszę, zamknij się i nie wtrącaj z byle gównem. Ps. Jestem za usunięciem postów-śmieci z tego wątku (w tym i mojego). -------------------- Łukasz Dywicki
Independent Java and open source software consultant. Blog - Java, OSGi, integracja oprogramowania.. |
|
|
26.05.2007, 18:27:32
Post
#33
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
splatch ty jakiś agresywny ostatnio jesteś
Sokal - ORM nie jest po to aby nie uczyć się SQL. Ideą (tak mi się przynajmniej wydaje) to zdjęcie z programisty powtarzania ciągle tych samych operacji na bazie danych. Ciagłego pisania banalnych selectów itd. W PHP w porównaniu z innymi językami duży procent rzeczy, które robisz są "banalne", dlatego, że nie ma narzędzi automatyzujących pracę, albo mało osób z nich korzysta. Powiem szczerze, że czasami jak pisze jakąś prostą stronkę to już mi się chce za przeproszeniem rzygać jak muszę napisać kolejny obiekt DAO, który w zasadzie robi to samo co inne tylko ma trochę inne nazwy pól itp. Dzięki Propelowi, frameworkom itd itp możesz skupić się na tych bardzie zawiłych rzeczach, a te rutynowe zostawiasz odpowiedniemu narzędziu. Co do tego, że ORM jest dla osób nie znających SQL to mam takie zdanie jak Mike - żeby napisać dobrze coś w ORM trzeba na prawdę orientować się jak działa SQL i w ogóle baza danych. Trzeba wiedzieć, kiedy użyć gotowych rozwiązań ORM, a kiedy warto rozszerzyć daną klasę np. o pobieranie kolekcji nietypowych elementów. Przykład z życia - masz sklep internetowy w którym produkty przynależą do różnych kategorii, mają różne stawki vat, marki, cechy. Liczba cech produktu jest zmienna. Każdy produkt ma różne progi rabatowe itd itp. Stajesz przed zadaniem pobrania x produktów z bazy z pełną informacją (czyli dodatkowe cechy, progi rabatowe itd). Gdybyś tutaj użył ORM'a bez własnej inwencji to położyłbyś bazę na łopatki ilością zapytań. Pół dnia zajęło mi, aby to zoptymalizować, napisać własne metody pobierania i wypełniania obiektów itd. Ale skutek jest taki, że dowolną ilość obiektów z bazy pobieram 2 zapytaniami Wcześniej jednak musiałem użyć tabel przejściowych, trochę cachowania itd. Mechanizmy Propela pozwoliły mi przebrnąć przez całe zadanie w miarę wygodnie - ale na pewno nie rozwiązały same mojego problemu - po prostu były punktem wyjścia. Swoją drogą było to fajne doświadczenie, bo rozwiązując kolejne problemy przejrzałem kod propela wzdłuż i wszerz - pewne rzeczy wydawały mi się na początku dziwne, ale potem często zauważałem ich uniwersalność i możliwość dostosowania całego narzędzia do swoich potrzeb. |
|
|
31.05.2007, 14:10:14
Post
#34
|
|
Grupa: Zarejestrowani Postów: 367 Pomógł: 10 Dołączył: 20.05.2005 Ostrzeżenie: (0%) |
Nie ukrywam, temat dość ciekawy.
Nie wiem jednak czy dobrze to zrozumiałem, a nie chce tkwić w błędzie dlatego napisałem:
Jest to oczywiście bardzo prosty przykład, posiadający jedynie możliwośc pobierania wyników. Moje pytanie brzmi: Czy ide w dobrym kierunku czy kompletnie nie zrozumiałem ORM? |
|
|
31.05.2007, 17:40:38
Post
#35
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) |
Moje pytanie brzmi: Czy idę w dobrym kierunku czy kompletnie nie zrozumiałem ORM? Idziesz w prawie dobrym kierunku. Ideą stosowania mapowań jest wykluczenie klepania SQLa na każdą potrzebę, a w tym momencie, mimo tego, że wynik masz reprezentowany w postaci obiektu, a nie różni się to od:
Owszem, umiejętność interpretacji każdego zapytania to cenna funkcjonalność, ale nie zapominaj o tym, że zależy Ci na obiektach jako takich a nie płaskich strukturach pokroju tablicy, a taki efekt uzyskujesz korzystając z __get (zwracasz po prostu kolumnę z wyniku nie zwracając uwagi na to z jakiego obiektu to jest property). Zwróć uwagę, że tu nie ma obiektu. Nie możesz odczytanych wartości zmodyfikować i zapisać. Obiekt Query może się przydać przy mapowaniu zapytań, ale raczej nie przy ich interpretowaniu. Kilka przykładów użycia "klasycznego" ORM:
Pamiętaj, że różnice implementacji przy różnych ORMach są czasami olbrzymie, zawsze możesz znaleźć swoją własną implementację bazując na dostępnych wzorcach. -------------------- Łukasz Dywicki
Independent Java and open source software consultant. Blog - Java, OSGi, integracja oprogramowania.. |
|
|
2.06.2007, 13:28:42
Post
#36
|
|
Grupa: Zarejestrowani Postów: 634 Pomógł: 14 Dołączył: 27.05.2006 Skąd: Berlin Ostrzeżenie: (0%) |
Witam,
Chciałbym się odnieść do wypowiedzi paru osób które uważają ze ORM-y to tylko ułatwienie dla programisty, i ze jest ucieczka od nauki SQL-a. Najważniejszą idea systemów ORM jest wspomaganie idei Domain-Driven-Develpment (DDD) która przeważnie jest podzielona na warstwy takich jak:
Drugim bardzo ważnym argumentem przemawiającym za ORM-ami jest zasada DRY (Don't Repeat Yourself). gdyż obiekty z Business Entities nierzadko biorą udział w Service Layer czyli w warstwie odpowiedzialna za eksponowanie funkcjonalności aplikacji za pośrednictwem Web Services. Używając SQL-a i tak byś musiał operować na obiektach by móc reprezentować dane w wspomnianej Service Layer, tak wiec musiałbyś najpierw wyciągać dane z tych obiektów, następnie zapisywać do bazy SQL-em a w razie potrzeby znowu wyciągać te dane sql-em i zapisywać do obiektów. UI tez czesto uzywa Business Entities... I jeszcze jedno: używając systemu ORM, możemy wymusić walidacje danych z poziomu samych obiektów poprzez umieszczanie logiki walidacyjnej w setter-ach. W przypadku SQL-a byłoby kilka if() else() przed zapisem. Dla tych którzy maja bardzo duże wątpliwości co do ORM-ow zalecam przyjrzenie się bardziej dojrzałym produktom takim jak (N)Hibernate, gdzie to ORM może zapisywać dane do prywatnych pól, które są i tak nie eksponowane przez obiekt a wykorzystywane w operacjach logicznych. Pozdrawiam |
|
|
12.06.2007, 17:33:19
Post
#37
|
|
Grupa: Zarejestrowani Postów: 237 Pomógł: 1 Dołączył: 8.02.2007 Ostrzeżenie: (10%) |
Chyba mnie przekonaliście do ORM-a
Propel jest zajebiaszczo prosty w obsłudze, a możliwości są wielkie. Miałem po prostu złe doświadczenia z ORM'em po poznaniu CodeIgniter'a. A kiedy chciałem poznać Propel to miałem same problemy, a to nie ma rozrzerzenia PHP - xslt (które było) a to co innego ... W piątek spróbowałem jeszcze raz, a wcześniej jakiś tydzień temu w Symfony. Wszystko działa super // Za moje poprzednie posty przepraszam. Ten post edytował Sokal 12.06.2007, 17:57:50 -------------------- Jabber/E-Mail: dominiksokal[at]gmail.com | GG: #3795571
|
|
|
6.07.2007, 01:05:47
Post
#38
|
|
Grupa: Zablokowani Postów: 167 Pomógł: 2 Dołączył: 15.02.2004 Ostrzeżenie: (30%) |
Jakie znacie lub macie u siebie zaimplementowane sposoby rozwiązania problemu z relacjami pomiędzy tabelami? Jak rozwiązujecie konieczność pobrania danych z bazy danych przy złożonym warunków opierającym się o dwie tablice?
|
|
|
6.07.2007, 01:15:01
Post
#39
|
|
Grupa: Przyjaciele php.pl Postów: 2 923 Pomógł: 9 Dołączył: 25.10.2004 Skąd: Rzeszów - studia / Warszawa - praca Ostrzeżenie: (0%) |
Takie cos jest w ORMach zaimplementowane. Patrz np propel http://propel.phpdb.org/trac/wiki/Users/Do...3/Relationships
-------------------- |
|
|
6.07.2007, 01:17:38
Post
#40
|
|
Grupa: Zarejestrowani Postów: 2 262 Pomógł: 21 Dołączył: 3.05.2004 Skąd: Sopot, Krakow, W-wa Ostrzeżenie: (0%) |
lub w phpDoctrine
-------------------- Javascript, Coffeescript, Node.js, Mongo, CouchDb, chmury, workery & inne bajery - zycie jest zbyt krotkie aby miec nudna prace :)
|
|
|
Wersja Lo-Fi | Aktualny czas: 27.09.2024 - 02:08 |