Łukasz C.

Łukasz C. Senior Technical
Architect

Temat: Frameworki do ORM w PHP

no jak im piszesz na ircu w podobnym tonie jak tutaj to ja sie wcale nie dziwie ze ci wala pokazali :p
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Frameworki do ORM w PHP

Taki mały apel do wszystkich: rozmawiajmy merytorycznie, a nie jak "dzieci neostrady" ;), może ktoś ma coś do powiedzenia jeszcze w tym temacie zamiast robić personalne przepychanki ?
Andrzej Martynowicz

Andrzej Martynowicz Starszy inżynier
oprogramowania
(Java/JEE), Tieto
Poland

Temat: Frameworki do ORM w PHP

"dzieci neostrady" ;)

Hehe.. dobre :)
Jest oczywiście Liquibase, ale IMHO wygodniej zarządzać zmianami w kodzie,
niż w bazie.

Dokładnie tak. Generlanie, aby ułatwić sobie utrzymanie aplikacji powinno się dążyć do trzymania wszystkiego w jednym miejscu. Dobrym przykładem na to są wspomniane adnotacje (wspierane właśnie przez Doctrine 2.0), które pozwalają zapisywać definicje mapowań w kodzie klas, zamiast w zewnętrzynych plikach mapujących.

@Przemek Czekaj: Widoki, widoki i jeszcze raz widok

Dzięki za ten hint, bo pomysł moim zdaniem w sumie nie jest aż taki zły:)... ale ja w sumie też widoki raczej omijam, jeśli nie muszę z nich skorzystać, bo to dodatkowa rzecz którą trzeba zarządzać razem z rozwojem aplikacji.

No i jeszcze słowo na temat developerów doctrine. Jeśli chodzi o mnie to spojrzenie na koncepcję wersji D2.0 daje mi jednak wrażenie, że goście wiedzą co robią :)
Marcin Molga

Marcin Molga Senior Solution
Architect, IBM.

Temat: Frameworki do ORM w PHP

Wojciech Soczyński:
jak "dzieci neostrady" ;), może ktoś ma coś do powiedzenia jeszcze w tym temacie zamiast robić personalne przepychanki ?

Ma. Ale to już w temacie upgrade'u wersji z 1.1.4 na 1.2.2:
1. w 1.2.2 zmieniły się nazwy kilku metod, np.: Doctrine_Search_Query::getSql() na getSqlQuery() czy Doctrine_RawSql::getCountQuery() na getCountSqlQuery(); zmiana nic nie wnosząca, a upierdliwa; mogliby chociaż oznaczyć je jako Deprecated; co jeżeli w kolejnej wersji nazwy zmienią bardziej kluczowe metody?
2. o ile pamiętam, w wersji 1.1.4 pusty string i null były traktowane tak samo - jako null do bazy. W wersji 1.2.2 są już rozróżniane, ale o zmianie słowa w dokumentacji nie było :)

Zatem: bez unit testów nie podchodzić.

Pozdrawiam.
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Frameworki do ORM w PHP

Marcin MOLGA:
Wojciech Soczyński:
jak "dzieci neostrady" ;), może ktoś ma coś do powiedzenia jeszcze w tym temacie zamiast robić personalne przepychanki ?

Ma. Ale to już w temacie upgrade'u wersji z 1.1.4 na 1.2.2:
1. w 1.2.2 zmieniły się nazwy kilku metod, np.: Doctrine_Search_Query::getSql() na getSqlQuery() czy Doctrine_RawSql::getCountQuery() na getCountSqlQuery(); zmiana nic nie wnosząca, a upierdliwa; mogliby chociaż oznaczyć je jako Deprecated; co jeżeli w kolejnej wersji nazwy zmienią bardziej kluczowe metody?
2. o ile pamiętam, w wersji 1.1.4 pusty string i null były traktowane tak samo - jako null do bazy. W wersji 1.2.2 są już rozróżniane, ale o zmianie słowa w dokumentacji nie było :)

Zatem: bez unit testów nie podchodzić.

Pozdrawiam.
Po 1.2.x nie będzie już żadnych nowych wersji Doctrine'a z lini 1.x, kolejna będzie 2.0 także nie ma ryzyka. Tak btw. bez sensu, że zmienili nazwy tych metod bo nic nowego nie wnoszą :>
Andrzej Martynowicz

Andrzej Martynowicz Starszy inżynier
oprogramowania
(Java/JEE), Tieto
Poland

Temat: Frameworki do ORM w PHP

Ta zmiana nazw method to faktycznie trochę źle świadczy o developerach. W
wersji 2.0 widzę, że próbują się trochę wzorować na nazwach z JPA, więc jest szansa, że takich akcji nie będą robić.... choć skoro aktualna wersja jest oznaczona jako beta to szczerze mówiąc zacznam już sie wahać czy nie poczekać na wersję stabilną przez użyciem :)Andrzej Martynowicz edytował(a) ten post dnia 12.08.10 o godzinie 17:01
Mateusz Kurtas

Mateusz Kurtas programista
PHP(senior)/Kohana(s
enior)/Laravel(middl
e)/Dr...

Temat: Frameworki do ORM w PHP

Zend Framework + Doctrine sprawuje się świetnie!
Andrzej Martynowicz

Andrzej Martynowicz Starszy inżynier
oprogramowania
(Java/JEE), Tieto
Poland

Temat: Frameworki do ORM w PHP

Mateusz Kurtas:
Zend Framework + Doctrine sprawuje się świetnie!

Ok dzięki za hint... osobiście lubię CodeIgniter'a i właśnie na pierwszy rzut przetestuję połączenie CodeIgnier + Doctrine 2.0 :)
Alan Gabriel B.

Alan Gabriel B. Software Engineer,
IFX

Temat: Frameworki do ORM w PHP

Andrzej Martynowicz:
CodeIgnier

a to to jeszcze żyje?

konto usunięte

Temat: Frameworki do ORM w PHP

Alan Gabriel B.:
Andrzej Martynowicz:
CodeIgnier

a to to jeszcze żyje?

Żyje, ale proponuje przerzucić się na kohanaPHP, bardzo przyjemny FW, a jesli znasz i, co ważniejsze, lubisz CI będziesz czuł sie jak ryba w wodzie... yyy kodzie ;-)Sebastian Zaborowski edytował(a) ten post dnia 16.08.10 o godzinie 23:25

konto usunięte

Temat: Frameworki do ORM w PHP

Ja używałem Propela i nie narzekam. Bardzo dobre rozwiązanie.
Andrzej Martynowicz

Andrzej Martynowicz Starszy inżynier
oprogramowania
(Java/JEE), Tieto
Poland

Temat: Frameworki do ORM w PHP

Ok Wojtek dzieki za info. Nie spotkałeś się z żadnymi problemami z properlem? Nie brakowało Ci czegoś może ?

konto usunięte

Temat: Frameworki do ORM w PHP

Andrzej Martynowicz:
Ok Wojtek dzieki za info. Nie spotkałeś się z żadnymi problemami z properlem? Nie brakowało Ci czegoś może ?

Jedyne czego brakowało to dobrych tutoriali, więc na początku był trudny do przejścia i być może to zdecydowało że nie jest aż tak popularny, jak widać powyżej. Czy realizacja relacji wiele-do-wielu była tak ważna, to bym się kłócił. Idea jest prosta jeśli mamy trzy tabele załóżmy Książki-Powiazanie-Muzeum, gdzie środkowa tabela to klasyczna tabela łącząca, to nie ma problemu - w klasie dziedziczącej po tej wygenerowanej dodajemy metodę getMuzeums() i w jej ciele robimy zapytanie poprzez tabele Powiazanie o rekordy tabeli Muzeum.

W ogóle najlepiej do każdej klasy wygenerowanej dodać klasę dziedziczącą, implementując w ten sposób klasyczny wzorzec dekorator. W ten sposób w przypadku zmian w bazie i automatycznym generowaniu xml-a (reverse-engineering struktury bazy), nie musimy ponownie wklejać napisanych przez nas samych metod przy klasie danej tabeli.

Kiedyś przeczytałem bardzo fajne stwierdzenie: wszyscy mówią że nie da się czegoś zrobić, aż znajduje się ktoś kto to zrobi ;-) Tak jest w tym wypadku - w taki powyższy sposób da się prosto zaimplementować relacje wiele-do-wielu. Dlatego też twórcy systemu nie uznali że to jest najważniejsze...Wojtek A. edytował(a) ten post dnia 26.08.10 o godzinie 19:39
Alan Gabriel B.

Alan Gabriel B. Software Engineer,
IFX

Temat: Frameworki do ORM w PHP

Sebastian Zaborowski:
Żyje, ale proponuje przerzucić się na kohanaPHP, bardzo przyjemny FW, a jesli znasz i, co ważniejsze, lubisz CI będziesz czuł sie jak ryba w wodzie... yyy kodzie ;-)

Symfony - zawsze i wszędzie, a wcześniej Agavi.

Kohana jest dla mnie za prosta (nie mówię o funkcjonalności tylko poziomie kodu) i za bardzo niestabilna, a potworki typu CI i Cake omijałem zawsze z daleka.
Piotr Wychowaniec

Piotr Wychowaniec Ekspert Magento,
Project Manager,
Starszy programista
PHP

Temat: Frameworki do ORM w PHP

Mateusz Kurtas:
Zend Framework + Doctrine sprawuje się świetnie!

Jaka jest przewaga Doctrine nad Zend_Db ?
Zend_Db to nie jest ORM ?

konto usunięte

Temat: Frameworki do ORM w PHP

Piotr Wychowaniec:
Mateusz Kurtas:
Zend Framework + Doctrine sprawuje się świetnie!

Jaka jest przewaga Doctrine nad Zend_Db ?
Zend_Db to nie jest ORM ?

Przeczytaj Zend_Db ostatni punkt w dokumentacji. Nie ma kaskadowego dodawania obiektów. Nie wiem jak w Doctrine, ale takie coś dla systemów ORM to podstawa.
Maciej Niedźwiecki

Maciej Niedźwiecki Born to rails hell

Temat: Frameworki do ORM w PHP

Używam Doctrine 1.2 bez żadnego problemu. Fakt, że ma jakieś parę małych niedociągnięć, ale jak się już je opanuje (w sensie "znajdzie obejście") to jest spoko.
Używałem z Zendem, Yii i Kohaną 2.3 i 3.0, chociaż KO3 ma jakiegoś swojego ORM'a, który wygląda na pierwszy rzut oka dość dobrze.

Temat: Frameworki do ORM w PHP

Na potrzeby swojej magisterki rok temu robiłem porównanie wydajności ORMów dla PHP i bezpośrednich zapytań SQL. Generalnie Doctrine był 1000 razy (!!!) wolniejszy od bezpośredniego selecta. Propel był wolniejszy o 2,5 rzędu wielkości.

Generalnie moim celem było napisanie swojego ORMa, który realizowałby zbliżoną do Doctrine funkcjonalność (aczkolwiek nie całą bo nie wszystko było mi potrzebne), natomiast głównym celem było wyciśnięcie maksymalnej wydajności.

Udało się napisać coś co wyczerpywało moje potrzeby (niewiele mniejsza funkcjonalność od Doctrina), a było szybsze od Propela. Natomiast i tak było to 100 razy wolniejsze od bezpośrednich zapytań SQL więc ostatecznie po obronie wsadziłem to głęboko do szuflady b taki wynik i tak był dla mnie dalece niesatysfakcjonujący. Operacje rezerwacji i zapisu do pamięci w PHP to wydajnościowy koszmar.
Paweł Koralewski

Paweł Koralewski architekt aplikacji,
team leader

Temat: Frameworki do ORM w PHP

Udało się napisać coś co wyczerpywało moje potrzeby (niewiele mniejsza funkcjonalność od Doctrina), a było szybsze od Propela. Natomiast i tak było to 100 razy wolniejsze od bezpośrednich zapytań SQL więc ostatecznie po obronie wsadziłem to głęboko do szuflady b taki wynik i tak był dla mnie dalece niesatysfakcjonujący. Operacje rezerwacji i zapisu do pamięci w PHP to wydajnościowy koszmar.

A w jaki sposób teraz piszesz komunikację z bazą w swoich aplikacjach? I jak z zarządzaniem tym kodem przy zmianie struktury bazy?

Temat: Frameworki do ORM w PHP

ja preferuje i polecam yii

Następna dyskusja:

Frameworki (PHP/PHP5)




Wyślij zaproszenie do