Czy powinienem wybrać Doctrine 2 lub Propel 1.5 / 1.6 i dlaczego? [Zamknięte]


30

Chciałbym usłyszeć od tych, którzy używali Doctrine 2 (lub nowszej wersji) i Propel 1.5 (lub nowszej wersji). Większość porównań między tymi dwoma mapującymi relacyjnymi obiektami opartymi jest na starych wersjach - Doctrine 1 vs. Propel 1.3 / 1.4, i obie ORM przeszły znaczące przeprojektowania w swoich ostatnich wersjach. Na przykład większość krytyki Propela wydaje się koncentrować wokół klas „ModelName Peer ”, które w każdym razie są przestarzałe w wersji 1.5.

Oto, co zgromadziłem do tej pory (I starałem się, aby ta lista była jak najbardziej zrównoważona ...):

  • Napędzać
    • Plusy
      • Niezwykle przyjazny dla IDE, ponieważ generowany jest rzeczywisty kod, zamiast polegać na magicznych metodach PHP. Oznacza to, że funkcje IDE, takie jak uzupełnianie kodu, są w rzeczywistości pomocne.
      • Szybko (pod względem użycia bazy danych - w bazie danych nie jest wykonywana introspekcja)
      • Czysta migracja między wersjami schematów (przynajmniej w wersji beta 1.6)
      • Może generować modele PHP 5.3 (tj. Przestrzenie nazw)
      • Łatwo połączyć wiele rzeczy w jedno zapytanie do bazy danych za pomocą useXxxmetod takich jak metody. (Zobacz film „Uzupełnianie kodu” powyżej)
    • Cons
      • Wymaga dodatkowego kroku kompilacji, a mianowicie zbudowania klas modeli.
      • Wygenerowany kod wymaga przebudowy przy każdej zmianie wersji Propela, zmianie ustawienia lub zmianie schematu. Może to być nieintuicyjne w przypadku niektórych i metody niestandardowe zastosowane w modelu zostaną utracone. (Myślę?) - Nieprawda; metody niestandardowe nie są tracone, ponieważ wygenerowana klasa jest klasą podstawową; Propel zapewnia klasę encji specjalnie dla rozszerzenia.
      • Niektóre przydatne funkcje (np. Zachowanie wersji, migracje schematów) mają status wersji beta.
  • Doktryna
    • Plusy
      • Bardziej popularny
      • Doctrine Query Language może wyrażać potencjalnie bardziej skomplikowane relacje między danymi, niż jest to łatwo możliwe dzięki strategii ActiveRecord firmy Propel.
      • Łatwiej jest dodać zachowania wielokrotnego użytku w porównaniu z Propelem.
      • Komentarze oparte na DocBlock do budowania schematu są osadzone w rzeczywistym PHP zamiast w osobnym pliku XML.
      • Korzysta z przestrzeni nazw PHP 5.3 wszędzie
    • Cons
      • Wymaga nauki całkowicie nowego języka programowania (Doctrine Query Language)
      • Wdrożono je w kilku „magicznych metodach”, dzięki czemu autouzupełnianie IDE jest bezwartościowe.
      • Wymaga introspekcji bazy danych, dlatego domyślnie jest nieco wolniejsza niż Propel; buforowanie może to usunąć, ale buforowanie powoduje znaczną złożoność.
      • Mniej zachowań jest zawartych w podstawowej bazie kodu. Kilka funkcji oferowanych przez Propela (takich jak Zestaw zagnieżdżony) jest dostępnych tylko poprzez rozszerzenia.
      • Zajebiście OGROMNY :)

Zebrałem to jednak tylko poprzez lekturę dokumentacji dostępnej dla obu narzędzi - właściwie nie zbudowałem jeszcze niczego.

Chciałbym usłyszeć od tych, którzy używali obu narzędzi, aby podzielić się swoimi doświadczeniami na temat zalet / wad każdej biblioteki i jakie są ich rekomendacje w tym momencie :)


O której wersji Doctrine mówisz? v2 i v1.2 są biegunami od siebie.
Orbling

1
@Orbling: Czy przeczytałeś tytuł lub treść pytania? Przeczytaj je jeszcze raz :)
Billy ONeal

@Billy ONeal: Dobra uwaga. Doctrine2 ma zachowania całkowicie usunięte z rdzenia, więc pomyślałem, że zamiast tego mówiłeś o wersji 1.2.
Orbling

@Orbling: Ach, to ma sens. Z drugiej strony zapewnia odpowiedniki „zachowań” - po prostu ich tak nie nazywa.
Billy ONeal

@Billy ONeal: Tak naprawdę nie można, możesz je zaimplementować w dość prosty sposób lub możesz uzyskać wtyczki innych firm. Ale to nie jest tak jak Doctrine1 lub Propel.
Orbling

Odpowiedzi:


15

Mimo obecnego trendu zalecania Doctrine, muszę powiedzieć inaczej. Pamiętaj też, że moje osobiste preferencje są zorientowane na moje osobiste doświadczenia, ale jak powiedział @Dan, oba są bardzo silne.

Nie lubię Nauki dla kilku powodów, wymienionych wcześniej, jak wielkość i całych metod magicznych thingy są te wyłączniki deal ze mną. Więc używam Propela , dlaczego? głównie dlatego, że jest prostota, a ponieważ proste w tworzeniu oprogramowania jest dobre . Osobiście uważam, że chciwość w projektowaniu jest zła.

Korzystając z Propela, udało mi się zaimplementować implementację wzorca repozytorium dla moich własnych systemów i działa naprawdę dobrze, nie wspominając o wydajności Propela, który jest jednym z najszybszych ORM, jakie widziałem.

Tak więc moją podstawową odpowiedzią jest Propel , ponieważ zapewnia dobre oprogramowanie z mniejszym kodem i umożliwia IDE dostarczenie ci dobrej inteligencji bez utraty oprogramowania ORM, które łączy się z bazą danych i robi to dobrze ...

Mam nadzieję, że mogę pomóc


Korzystałem z Doctrine przez rok. Próbowałem Kohana, Laravel Eloquent, lubię ich publiczne pola, bo naprawdę nie lubię osób pobierających i ustawiających (wolę dostęp do nieruchomości: P). Po tym, jak zobaczyłem w Propelu słowo „przyjazny dla IDE”, postanowiłem wypróbować Propel dziś wieczorem.
Zorji,

11

Twoje informacje o Doctrine 2 są nieprawidłowe ...

  • DQL jest w dużej mierze SQL, więc nie wiele się uczy.
  • Doctrine 2 nie używa żadnej „magii” (tylko tego, czego można oczekiwać w każdej nowoczesnej bibliotece PHP).
  • Doctrine 2 nie aktywnie wykonuje introspekcji bazy danych ... mapowanie jest przechowywane w twoich bytach / plikach mapowania i zakłada, że ​​baza danych będzie do tego pasować.
  • Buforowanie nie jest „znaczną złożonością”.
  • Doctrine 2 nie ma „zachowań” od razu po wyjęciu z pudełka

Nie korzystałem wcześniej z Propela, ale Doctrine 2 jest znacznie nowszy i ma bazę kodową naprawdę wysokiej jakości. Wygląda jednak na to, że Propel używa Active Record, Doctrine 2 używa wzorca Data Mapper.

Minusem nowszej wersji Doctrine 2 jest brak przykładów innych firm, ale szybko się rozwija.

Polecam Doctrine 2 ...


Jeśli wcześniej nie korzystałeś z Propela, to nie mam innego wyboru, jak zlekceważyć to z powodu bycia FUD. Jeśli chodzi o komentarz „Magia”, mam na myśli to, że opiera się on na magicznych metodach PHP, takich jak __geti __set(co jest prawdą), a nie na metodach rzeczywistych.
Billy ONeal 30.03.11

1
Ok za głosowanie w dół ... Ale gdzie Doctrine 2 używa magicznych metod? Pomijając metody znajdowania * DocumentRepository (__call), ale to nie jest problem, ponieważ jest to tylko lepszy sposób wysyłania zapytań ... zawsze stracisz autouzupełnianie IDE. Jeśli chcesz ActiveRecord użyj Propela. Jeśli chcesz Mapera danych, skorzystaj z Doctrine 2.
Cobby

2
Propel nie introspekcji bazy danych w czasie wykonywania dzięki generowaniu kodu.
William Durand,

Punkt 1 nie jest do końca poprawny, DQL nie jest „całkiem” jak SQL. DQL zależy od tego, że odwołujesz się do obiektów modelu, o których Doctrine musi wiedzieć, i są pewne komplikacje, jeśli konieczne są bardziej złożone sprzężenia.
Mike Purcell

2
DQL jest dialektem języka SQL. Jak to się dzieje, że nie jest tak „podobny” jak SQL? Tak, semantyka języka jest nieco inna (obiekty vs. tabele), ale ostatecznie DQL jest językiem do wyszukiwania danych strukturalnych - które akurat były reprezentowane jako obiekty, a nie tabele - czyli SQL.
Cobby

3

Z twoich komentarzy wynika, że ​​próbujesz wybrać Propel lub Doctrine, aby zastąpić lub zaspokoić potrzebę ORM w starszej aplikacji.

Biorąc to pod uwagę, uważam, że ważne jest, aby nie stracić z oczu faktu, że przejście do jednego z nich może być świetnym ulepszeniem aplikacji. Tak więc nie ma naprawdę złej odpowiedzi.

Dlatego wybrane rozwiązanie zależy w dużej mierze od twoich preferencji na podstawie odpowiedzi na następujące pytania:

  1. Który najlepiej zintegrować z Twoim obecnym rozwiązaniem?
  2. Który interfejs API preferujesz?
  3. Do którego wolisz przyczynić się? (łatki, dokumentacja, raporty błędów itp.)

Osobiście poleciłbym Doctrine 2 ze względu na jego społeczność, dokumentację i architekturę.


1
Szukam tutaj porównania między nimi. (Dlaczego taki, który wolałbym mieć znaczenie? Nie chcę brać udziału w żadnym z nich - chcę korzystać z biblioteki, a nie pisać!;)). Mówisz, że Doctrine 2 ma dobrą społeczność, dokumenty i architekturę - jeśli chodzi o architekturę, tak, to DataMapper. Dokumenty mądre Nie jestem pewien, czy się zgadzam - oba projekty wydają się mieć dobre dokumenty. Nie widziałem żadnej społeczności używającej żadnego z tych systemów. Czy chciałbyś wyjaśnić, co masz na myśli przez te rzeczy?
Billy ONeal

2
Och, podoba ci się dokument Doctrine? Czy czytałeś Propela? I tak, społeczność Doctrine jest miła, ale spójrz na repozytorium ODM, wiele PR nie jest nawet komentowanych, łączonych ani odrzucanych… Spójrz na oś czasu Propela, społeczność jest naprawdę aktywna;)
William Durand

3

Polecam Ci Propela, ponieważ jest dobrze zintegrowany, szybki i wydajny. Generowanie kodu jest lepsze niż ładowanie klas w środowisku wykonawczym, ułatwia debugowanie i pokazuje, co stworzyłeś. Zatem krok kompilacji nie stanowi problemu.

Doctrine2 nie ma oficjalnych zachowań, a wzorzec projektowy DataMapper jest fajny, ale trudny w użyciu w prawdziwym życiu. Aha, a DQL to bolesny, ale niepoprawny język do nauki ...

Jeśli chcesz myśleć o obiektach (bez DQL / SQL / cokolwiek), wybierz Propel.

Doctrine2 jest de facto częścią Symfony2, ale wszystko potoczy się wkrótce, spójrz na ostatni artykuł Fabien Potencier.

Na zdrowie, Williamie


, zacząłem od Propela 2 lata temu z symfony1. następnie musiałem przejść do Doctrine2 dla symfony2. Z przyjemnością wracam do Propel.Cheers!
Bhanu Krishnan

2

Oboje są bardzo dobrzy. Istnieje kilka skrajnych przypadków, w których można coś zrobić lub zrobić coś lepszego niż drugi. Gdziekolwiek miałem problemy z którymkolwiek z nich, wynikało to bardziej z mojego braku wiedzy niż z czegoś, czego nie mogli zrobić.

Oznacza to, że dokumentacja i wsparcie są ważniejsze niż wewnętrzna zdolność kodu. Czy znasz kogoś, kto może ci pomóc, gdy napotkasz problemy? Jak dobrze radzisz sobie z dokumentacją? Czy któryś z nich po prostu „wydaje ci się bardziej naturalny”?


2

Wybrałem Propel 1.63 dla dużej starszej aplikacji mysql (około 200 tabel) - uwzględniono tu następujące czynniki: wsparcie IDE, które umożliwia nowym programistom łatwe znalezienie drogi dzięki uzupełnieniu kodu; obsługa schematów między bazami danych, wydajność; lepsze natywne wsparcie dla wyliczeń i stosowanie kilku zachowań. Właściwie zacząłem od Doctrine, ponieważ był on najlepiej obsługiwany przez Symfony2, ale gdy Propel znacznie poprawił ich wsparcie z Symfony (kolejną platformą, do której ostatecznie przeprowadzę migrację), przełączyłem się z powodu lepszej obsługi powyższych problemów. W ogóle nie żałuję Propel jest decydującym zwycięzcą.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.