Łukasz
C.
Senior Technical
Architect
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
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
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
Programista
eksplorator -
blog.wsoczynski.pl
Temat: Frameworki do ORM w PHP
Marcin MOLGA: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ą :>
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.
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. Wwersji 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
programista
PHP(senior)/Kohana(s
enior)/Laravel(middl
e)/Dr...
Temat: Frameworki do ORM w PHP
Zend Framework + Doctrine sprawuje się świetnie!
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.
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
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.
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
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 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.
Wojciech Małota Programista
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
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?
Rafal Yeld inwestor
Temat: Frameworki do ORM w PHP
ja preferuje i polecam yiiPodobne tematy
-
PHP » Frameworki (PHP/PHP5) -
-
PHP » nowe frameworki dla PHP -
-
PHP » php proxy ftp -
-
PHP » php curl ftp download plików po dacie modyfikacji i po... -
-
PHP » php wyciąganie danych z pliku tekstowego -
-
PHP » Darmowy skrypt PHP do testów (quizów) online -
-
PHP » Jak zapisac dane z php w access log'u (nginx)? -
-
PHP » Programista PHP- projekt w Poznaniu -
-
PHP » counter.php -
-
PHP » Różnice w wynikach z JS i PHP -
Następna dyskusja: