GoldenLine
Zaloguj się
Paweł Koralewski

Paweł Koralewski architekt aplikacji,
team leader

Temat: Doctrine/Propel czy coś prostszego

Zdecydowałem się na umieszczenie jak największej ilości logiki biznesowej w bazie, stąd mój wybór padł na PostgreSQL (MySQL nie pozwala tworzyć triggerów przy niskich uprawnieniach, co jest częste na hostingach współdzielonych).

Dane będę pobierać tylko widokami, aktualizować tylko procedurami składowanymi. Czy zatem zysk na szybkości tworzenia programowania z użyciem dorosłego ORMa jest znaczący w porównianiu z czymś prostym (własnym), czyli zwykłym przerzutowaniem uzyskanych rekordów z bazy na tabelę potrzebnych w danym kontekście obiektów? Te klasy mogę pisać ręcznie, nie powinny być skomplikowane, a pomogą przy IntelliSense w IDE.
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

Przy takim podejściu raczej nie ma sensu stosować ORMa :)
Link do wypowiedziLink
Paweł Koralewski

Paweł Koralewski architekt aplikacji,
team leader

Temat: Doctrine/Propel czy coś prostszego

Jesteś moim bogiem.

No dobra, bożkiem :):)

Sensu trochę jest, bo w tych prostych klasach nie będą tylko pola z bazy, ale mogą też trafić się funkcje. No i pomoc w IDE jest bezcenna.
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

No sens jest stworzyć swoje proste klasy do obsługi tego typu działań, bo skoro wyciągasz dane widokiem a nie żadnym DQLem (Doctrine) oraz utrwalasz je procedurą to średnio gdzie tu jest możliwość wykorzystania mocy ORMa. Taka moja opinia ;)
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

A co ma ORM do widoków? Bo nie za bardzo zrozumiałem. Ja np w niektórych projektach używam widoków i mapuje je przez ORM na obiekty, bo po prostu to jest najwygodniejsze. Nie widzę jakichkolwiek przeciwwskazań do zastosowania ORM-a.
Przecież nie ma znaczenia czy dane pochodzą ze zwykłego selecta czy z widoku.
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

I co mam manualnie tworzyć odwzorowanie widoku na obiekt? Chyba, że znasz jakąś magiczną sztuczkę że Doctrine sam mi zmapuje fajnie to co jest w widoku, wszystkie ewentualne county, joiny, uniony, itp. to ja naprawdę chętnie się dowiem :)
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

W przypadku Doctrine nie używałem widoków i z tego ci widzę, to raczej jest tam tylko namiastka obsługi widoków:
http://www.doctrine-project.org/blog/using-views-with-...

Ale już np. w przypadku Propela nie stanowi to większego problemu:
http://blog.chylek.pl/2009/02/07/symfony-przyspieszani...
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

Aleksander Wons:
W przypadku Doctrine nie używałem widoków i z tego ci widzę, to raczej jest tam tylko namiastka obsługi widoków:
http://www.doctrine-project.org/blog/using-views-with-...

Ale już np. w przypadku Propela nie stanowi to większego problemu:
http://blog.chylek.pl/2009/02/07/symfony-przyspieszani...

No w Doctrine to jest jakaś lipa. Pisanie skomplikowanych widoków za pomocą Doctrine to jest jakiś masochizm. Propela nie znam, więc nie będę zgadywał jak to tam działa.

Ogólnie dla mnie głownym zbawiennym działaniem ORMa (np. Doctrine) jest to, że zrobię sobie instancję odwzorowującą jedną tabelę i w łatwy sposób mogę dostawać się do pól jej relacji, lub te relacje zapisywać. Np. $oUser->UserGroup->group_name

Z widoków generalnie tylko wyciągamy dane więc w sumie, więc w moim rozumieniu zastosowanie ORMa było tam zbędne. W prosty sposób mogę wykonać select z widoku w PDO i dostać kolekcję
wyników. A nie muszę nic konfigurować ani nie mam takiego narzutu...

Tak się zastanawiam nad jakimś przykładowym case'em w którym zastosowanie ORMa do widoków miało by wymierną korzyść... I jak na razie nie wpadłem na nic :)Marcin Olichwirowicz edytował(a) ten post dnia 07.08.10 o godzinie 15:41
Link do wypowiedziLink
Michał Gozdera

Michał Gozdera Development Team
Manager, PayU S.A. /
IT Toruń

Temat: Doctrine/Propel czy coś prostszego

Na moje oko, jeśli planujesz całą logikę zaszyć w widokach to poza prostszym kodowaniem ze względu na odwzorowanie tabel na obiekty nic nie zyskujesz, orm nie jest więc potrzebny.

Inna sprawa, że nie widzę powodu, dla którego warto całą logikę zaszywać w bazie. Masz przykład jakiegoś case'a w którym jest z tego zysk??
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

Prosty przykład.
Sprzedajemy książki. Wystawiamy fakturę. Na fakturze mamy poszczególne pozycje. Wiadomo, że nie potrzebujemy wszystkich informacji o książce, więc sensownym rozwiązaniem jest widok.
Chcemy wyświetlić podsumowanie faktury: cenę netto, brutto, koszty transportu, upusty. Jasne, że można zrobić dodatkowych X zapytań do bazy i wyciągnąć te dane. Ale tutaj moim zdaniem lepsze rozwiązanie to zmapować widok do obiektu i przy pomocy prostej funkcji wybrać te dane już przy pomocy samego PHP. To samo tyczy się np cen netto/brutto poszczególnych pozycji. Jasne, że można foreach-em jechać


echo $pozycja['netto'];

echo $pozycja['netto']+$pozycja['netto']*0.22;

tylko ja jakoś zawsze wolałem takie rozwiązanie


echo $pozycja->getPrice(); // netto

echo $pozycja->getPrice(true); // brutto


No ale to moje subiektywne odczucie. No wszystko zależ od tego, czy będziemy potrzebowali w jakikolwiek sposób przetwarzać dane, czy po prostu operujemy na czystych polach z bazy.
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

Aleksander Wons:
Jasne, że można foreach-em jechać


echo $pozycja['netto'];

echo $pozycja['netto']+$pozycja['netto']*0.22;

tylko ja jakoś zawsze wolałem takie rozwiązanie


echo $pozycja->getPrice(); // netto

echo $pozycja->getPrice(true); // brutto


No ale to moje subiektywne odczucie. No wszystko zależ od tego, czy będziemy potrzebowali w jakikolwiek sposób przetwarzać dane, czy po prostu operujemy na czystych polach z bazy.

Ja osobiście bym tak napisał widok, żeby nie trzeba było już tak przetwarzać jak to dałeś w przykładzie.

Aczkolwiek tak czytając to, przyszedł mi na myśl jeden plus obiektów ORMowych, które potrafią np. odpowiednio zrzutować od razu na określony typ.
Link do wypowiedziLink
Michał Gozdera

Michał Gozdera Development Team
Manager, PayU S.A. /
IT Toruń

Temat: Doctrine/Propel czy coś prostszego

Aczkolwiek tak czytając to, przyszedł mi na myśl jeden plus obiektów ORMowych, które potrafią np. odpowiednio zrzutować od razu na określony typ.

Można przecież napisać sobie metody do pobierania tych danych, które będzie się łatwo używać, do rzutowania na typy itd. które opakują ładnie całą komunikację z bazą bez całego nakładu dającego elastyczność orm-owi - tutaj widzę zysk z nie stosowania orma.

Dla mnie ten wątek jest ciekawy, dlatego, że nigdy nie przyszło mi do głowy wrzucanie logiki do bazy. Logikę realizowaną przez widoki można zaszyć w sensownej logice aplikacji, a przy tym na moje oko jest łatwiejsza w utrzymaniu, przy pracy na wydajności można łatwo dorzucić cache'owanie itd.

Może dopytuję, ale robię to nie ze złośliwości ale z ciekawości. Dlaczego chcesz realizować logikę w bazie?
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

Michał Gozdera:
Aczkolwiek tak czytając to, przyszedł mi na myśl jeden plus obiektów ORMowych, które potrafią np. odpowiednio zrzutować od razu na określony typ.

Można przecież napisać sobie metody do pobierania tych danych, które będzie się łatwo używać, do rzutowania na typy itd. które opakują ładnie całą komunikację z bazą bez całego nakładu dającego elastyczność orm-owi - tutaj widzę zysk z nie stosowania orma.

No wszystko można, tylko to już musisz albo z bazy pobierać informacje o typach danych w tabeli albo definiować pola tabeli w jakimś pliku... Ogólnie zaczyna się zamieszanie, żeby to było robione automagicznie :)
Dla mnie ten wątek jest ciekawy, dlatego, że nigdy nie przyszło mi do głowy wrzucanie logiki do bazy. Logikę realizowaną przez widoki można zaszyć w sensownej logice aplikacji, a przy tym na moje oko jest łatwiejsza w utrzymaniu, przy pracy na wydajności można łatwo dorzucić cache'owanie itd.

Może dopytuję, ale robię to nie ze złośliwości ale z ciekawości. Dlaczego chcesz realizować logikę w bazie?

Ależ można też cache'ować dane strickte na bazie. Zgodzę się, że debugowanie i maintenance takiej aplikacji jest nieco uciążliwy... Ale to też zależy jakiej bazy się używa i jakie ma się narzędzia dostępne.
Ja kiedyś pracowałem parę miesięcy przy projektach, gdzie cała logika była na bazie na procedurach i funkcjach, ot z założenia. Całkiem nieźle praca idzie:
Programista potrzebuje dostać z bazy dane takie, takie i takie dla danych wejściowych takich i takich -> request do bazodanowca, a za 15 minut dostaje się link do wiki z udokumentowaną procedurą ;)
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

Ja bym powiedział tak: o ile pozbyć się ORM-a można to już samych obiektów bym się nie pozbywał. Np PDO może hydrować obiekty i co za tym idzie można spokojnie ich używać. Jasne, że narzut jest ogromny w przypadku stosowania ORM-ów, ale maintenance takiej aplikacji o niebo prostszy (chociaż może to moje subiektywne odczucie).

Tak na prawdę można połączyć jedno i drugie. Część przez ORM a części prosto z bazy (możne nawet z pominięciem hydrowania obiektu). Wszystko zależy od konkretnego przypadku. Jestem właśnie na etapie kończenia projektu, w którym mam właśnie taki podział. Część idzie przez obiekty/orm a część bezpośrednio na bazie (widoki, triigery, procedury). Po prostu trzeba znaleźć złoty środek a nie popadać od razu w skrajności ;)
Link do wypowiedziLink
Paweł Koralewski

Paweł Koralewski architekt aplikacji,
team leader

Temat: Doctrine/Propel czy coś prostszego

Może dopytuję, ale robię to nie ze złośliwości ale z ciekawości. Dlaczego chcesz realizować logikę w bazie?

Kwestia wydajności aplikacji. Mogę zrobić sobie select z funkcji, która przeczesze mi całą bazę a w niej będzie skomplikowana logika. Jeśli miałbym pobrać to poza serwer bazodanowy, do przetrawienia przez PHP, to obciążone jest połączenie między serwerami. No i potem trzeba te dane przerobić na tabelki i przetrawić.

Kolejna zaleta to spójność danych - np. gdy przy dodawaniu nowej pozycji do faktury baza sama zmodyfikuje nagłówek faktury to już nie muszę w każdym miejscu dodawania nowej pozycji się o to martwić (niby ORM też to zapewnia, ale nie ma 100% pewności, że jakiś programista nie pójdzie "na skróty"). Przy ręcznym poprawianiu bazy w pgAdminie nagłówek faktury też mi się poprawi. No i wystarczy że zrobię jednego inserta, czyli tylko 1 zapytanie, resztę zrobi silnik, co też jest zdecydowanie szybsze.
Link do wypowiedziLink
Paweł Koralewski

Paweł Koralewski architekt aplikacji,
team leader

Temat: Doctrine/Propel czy coś prostszego

Tak na prawdę można połączyć jedno i drugie. Część przez ORM a części prosto z bazy (możne nawet z pominięciem hydrowania obiektu). Wszystko zależy od konkretnego przypadku. Jestem właśnie na etapie kończenia projektu, w którym mam właśnie taki podział. Część idzie przez obiekty/orm a część bezpośrednio na bazie (widoki, triigery, procedury). Po prostu trzeba znaleźć złoty środek a nie popadać od razu w skrajności ;)

Zgadzam się z Tobą, skrajności zawsze są złe. Jak napisałem na początku wątku, nie chcę całkowicie rezygnować z metodologii zbliżonej do ORM, tylko ją uprościć (w miarę potrzeby albo "gołe" rekordy albo hydrowanie).
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

Paweł Koralewski:
Tak na prawdę można połączyć jedno i drugie. Część przez ORM a części prosto z bazy (możne nawet z pominięciem hydrowania obiektu). Wszystko zależy od konkretnego przypadku. Jestem właśnie na etapie kończenia projektu, w którym mam właśnie taki podział. Część idzie przez obiekty/orm a część bezpośrednio na bazie (widoki, triigery, procedury). Po prostu trzeba znaleźć złoty środek a nie popadać od razu w skrajności ;)

Zgadzam się z Tobą, skrajności zawsze są złe. Jak napisałem na początku wątku, nie chcę całkowicie rezygnować z metodologii zbliżonej do ORM, tylko ją uprościć (w miarę potrzeby albo "gołe" rekordy albo hydrowanie).

W takim razie z czystym sumieniem mogę polecić Propela 1.5, bo bez problemów obsługuje widoki, które na pewno się przydają a i pozwala np. na hydrowanie wyników "on demand" (co zmniejsza zużycie pamięci - nie ma znaczenia, czy wybrałeś z bazy 5 wyników czy 5000). Poza tym jest na pewno wydajniejszy niż Doctrin i szybszy (w sensie czasu wykonania kodu, bo łatwość wybierania danych już jest podobna w Doctrine 1.2 i Propelu 1.5).
Link do wypowiedziLink
Paweł Koralewski

Paweł Koralewski architekt aplikacji,
team leader

Temat: Doctrine/Propel czy coś prostszego

Tylko Doctrine ma mieć natywne wsparcie w Symfony 2.0, co zapewne będzie ułatwieniem.
Link do wypowiedziLink

konto usunięte

Temat: Doctrine/Propel czy coś prostszego

Jeśli mowa o symfony 2 (wnioskuję, że od razu zaczynasz projekt w 2) to z tego co czytałem Propel 1.5 już nie ma przewagi wydajnościowej na Doctrine 2.0. Co do samego wsparcia czytałem, że można spokojnie używać i Doctrine i Propela 1.5 (Propel 1.5 śmiga pod PHP 5.3).
Niestety nie wiem, czy poprawili obsługę widoków w Doctrine 2.0.
Link do wypowiedziLink
Mateusz Mierzwiński

Mateusz Mierzwiński Programista, grafik,
specjalista ds.
social media,
aplika...

Temat: Doctrine/Propel czy coś prostszego

Paweł Koralewski:
Tylko Doctrine ma mieć natywne wsparcie w Symfony 2.0, co zapewne będzie ułatwieniem.

Ogólnie Doctrine to świetny ORM - cieszy mnie to, że będzie natywnie wspierana.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Symfony + TSearch2 (Propel ...




Wyślij zaproszenie do
Anuluj