Sollte ich Doctrine 2 oder Propel 1.5 / 1.6 wählen und warum? [geschlossen]


30

Ich würde gerne von denen hören, die Doctrine 2 (oder neuer) und Propel 1.5 (oder neuer) verwendet haben. Die meisten Vergleiche zwischen diesen beiden objektrelationalen Mappern basieren auf alten Versionen - Doctrine 1 versus Propel 1.3 / 1.4 - und beide ORMs wurden in ihren letzten Überarbeitungen erheblich überarbeitet. Zum Beispiel scheint sich die meiste Kritik an Propel auf die "ModelName Peer " -Klassen zu konzentrieren, die in jedem Fall in 1.5 veraltet sind.

Folgendes habe ich bisher gesammelt (und ich habe versucht, diese Liste so ausgewogen wie möglich zu gestalten ...):

  • Treiben
    • Vorteile
      • Sehr IDE-freundlich, da der eigentliche Code generiert wird, anstatt sich auf magische PHP-Methoden zu verlassen. Dies bedeutet, dass IDE-Funktionen wie die Code-Vervollständigung tatsächlich hilfreich sind.
      • Schnell (In Bezug auf die Datenbanknutzung wird keine Introspektion zur Laufzeit für die Datenbank durchgeführt.)
      • Saubere Migration zwischen Schemaversionen (mindestens in der Beta 1.6)
      • Kann PHP 5.3 Modelle generieren (zB Namespaces)
      • Einfache Verkettung vieler Dinge in einer einzelnen Datenbankabfrage mit useXxxMethoden. (Siehe das Video "Code-Vervollständigung" oben)
    • Nachteile
      • Erfordert einen zusätzlichen Build-Schritt, nämlich das Erstellen der Modellklassen.
      • Der generierte Code muss jedes Mal neu erstellt werden, wenn die Propel-Version geändert, eine Einstellung geändert oder das Schema geändert wird. Dies ist für einige möglicherweise nicht intuitiv, und benutzerdefinierte Methoden, die auf das Modell angewendet werden, gehen verloren. (Ich denke?) - Nicht wahr; Benutzerdefinierte Methoden gehen nicht verloren, da die generierte Klasse eine Basisklasse ist. Propel stellt eine Entitätsklasse speziell für die Erweiterung bereit.
      • Einige nützliche Funktionen (z. B. Versionsverhalten, Schema-Migrationen) befinden sich im Beta-Status.
  • Lehre
    • Vorteile
      • Bekannter
      • Doctrine Query Language kann möglicherweise kompliziertere Beziehungen zwischen Daten ausdrücken, als dies mit der ActiveRecord-Strategie von Propel ohne Weiteres möglich ist.
      • Im Vergleich zu Propel ist es einfacher, wiederverwendbare Verhaltensweisen hinzuzufügen.
      • DocBlock-basiertes Kommentieren zum Erstellen des Schemas wird anstelle einer separaten XML-Datei in das eigentliche PHP eingebettet.
      • Verwendet überall PHP 5.3 Namespaces
    • Nachteile
      • Erfordert das Erlernen einer völlig neuen Programmiersprache (Doctrine Query Language)
      • An mehreren Stellen mit "magischen Methoden" implementiert, wodurch die automatische Vervollständigung der IDE wertlos wird.
      • Erfordert Datenbank-Introspection und ist daher standardmäßig etwas langsamer als Propel. Zwischenspeichern kann dies beseitigen, aber das Zwischenspeichern erhöht die Komplexität erheblich.
      • Die Kerncodebasis enthält weniger Verhaltensweisen. Einige Funktionen, die Propel standardmäßig bereitstellt (z. B. "Verschachteltes Set"), sind nur über Erweiterungen verfügbar.
      • Freakin RIESIG :)

Dies habe ich allerdings erst durch Lesen der Dokumentation für beide Tools herausgefunden - ich habe eigentlich noch nichts gebaut.

Ich würde gerne von denen hören, die beide Tools verwendet haben, um ihre Erfahrungen mit den Vor- und Nachteilen der einzelnen Bibliotheken auszutauschen, und was ihre Empfehlung an dieser Stelle ist :)


Über welche Version von Doctrine sprechen Sie? v2 und v1.2 sind Pole voneinander entfernt.
Orbling

1
@Orbling: Hast du den Titel oder den Text der Frage gelesen? Lesen Sie sie noch einmal :)
Billy ONeal

@ Billy ONeal: Guter Punkt. In Doctrine2 wurden Verhaltensweisen so gut wie vollständig aus dem Core entfernt, daher dachte ich, dass Sie stattdessen über Version 1.2 gesprochen haben.
Orbling

@Orbling: Ah, das macht Sinn. Andererseits bietet es Äquivalente zu "Verhaltensweisen" - es nennt sie einfach nicht so.
Billy ONeal

@ Billy ONeal: Das ist nicht wirklich so. Sie können sie auf relativ einfache Weise selbst implementieren oder Plugins von Drittanbietern erwerben. Aber es ist nicht wie Doctrine1 oder Propel.
Orbling

Antworten:


15

Trotz des gegenwärtigen Trends, Doctrine zu empfehlen, muss ich etwas anderes sagen. Denken Sie daran, dass sich meine persönlichen Vorlieben auch an meinen persönlichen Erfahrungen orientieren, aber wie @Dan sagte, sind sie beide sehr wirkungsvoll.

Ich weiß nicht , wie Lehre für einige der Gründe , bevor Sie erklärt, wie die Größe und die ganzen magischen Methoden THINGY die sind Dealbreaker mit mir. Also, ich benutze Propel , warum? hauptsächlich, weil es einfach ist und weil einfach in der Softwareentwicklung gut ist . Mein persönlicher Glaube ist, dass es schlecht ist, mit Designs gierig zu werden.

Mit Propel habe ich es geschafft, eine Repository-Musterimplementierung für meine eigenen Systeme zu implementieren , und es funktioniert wirklich gut, ganz zu schweigen von der Leistung von Propel, einem der schnellsten ORMs, die ich je gesehen habe.

Meine grundlegende Antwort ist Propel , weil es eine gute Software mit weniger Code liefert und die IDE in die Lage versetzt, Ihnen ein gutes Verständnis zu vermitteln, ohne den Punkt der ORM-Software zu verlieren, die eine Verbindung mit der Datenbank herstellt und es gut macht ...

Hoffe ich kann helfen


Ich habe Doctrine ein Jahr lang angewendet. Ich habe Kohana ausprobiert, Laravel Eloquent, ich mag ihre öffentlichen Bereiche, weil ich Getter und Setter wirklich hasse (ich bevorzuge den Zugriff auf Immobilien: P). Nachdem ich das Wort 'IDE friendly' in Propel gesehen hatte, entschloss ich mich, es heute Abend mit Propel zu versuchen.
Zorji

11

Ihre Angaben zu Doctrine 2 sind falsch ...

  • DQL ist so ziemlich SQL, also nicht viel zu lernen.
  • In Doctrine 2 wird keine "Magie" verwendet (nur das, was Sie von einer aktuellen PHP-Bibliothek erwarten).
  • Doctrine 2 führt keine aktive Datenbankintrospektion durch. Die Zuordnung wird in Ihren Entitäten / Zuordnungsdateien gespeichert und setzt voraus, dass Ihre Datenbank dazu passt.
  • Caching ist kaum "erhebliche Komplexität".
  • In Doctrine 2 gibt es keine „Verhaltensweisen“, die nicht sofort einsatzbereit sind

Ich habe Propel noch nie benutzt, aber Doctrine 2 ist viel neuer und hat eine wirklich hochwertige Codebasis. Aber es sieht so aus, als ob Propel Active Record verwendet, Doctrine 2 verwendet das Data Mapper-Muster.

Der Nachteil von Doctrine 2, das neuer ist, ist das Fehlen von Beispielen von Drittanbietern, aber es baut sich schnell auf.

Ich empfehle Doctrine 2 ...


Wenn Sie Propel noch nicht verwendet haben, habe ich keine andere Wahl, als dies wegen FUD abzustimmen. Was den "Magic" -Kommentar betrifft, so meine ich, dass er auf PHP-Magic-Methoden wie __getund __set(was wahr ist) und nicht auf echten Methoden basiert .
Billy ONeal

1
Ok für die Down-Abstimmung ... Aber wo setzt Doctrine 2 magische Methoden ein? Abgesehen von den find * -Methoden von DocumentRepository (__call) ist dies jedoch kein Problem, da es sich lediglich um eine bessere Art der Abfrage handelt. Sie verlieren immer die IDE-Autovervollständigung. Wenn Sie ActiveRecord verwenden möchten, verwenden Sie Propel. Wenn Sie Data Mapper möchten, verwenden Sie Doctrine 2.
Cobby

2
Propel überprüft die Datenbank dank der Codegenerierung nicht zur Laufzeit.
William Durand

Aufzählungspunkt 1 ist nicht ganz richtig, DQL ist nicht "so ziemlich" wie SQL. DQL hängt von der Tatsache ab, dass Sie auf Modellobjekte verweisen, die Doctrine kennen muss, und es gibt einige Komplikationen, wenn komplexere Verknüpfungen erforderlich sind.
Mike Purcell

2
DQL ist ein SQL-Dialekt. Wie kann das dazu führen, dass es nicht wie SQL ist? Ja, die Semantik der Sprache ist etwas anders (Objekte vs. Tabellen), aber letztendlich ist DQL eine Sprache zum Abfragen von strukturierten Daten - die zufällig als Objekte und nicht als Tabellen dargestellt wurden - aka SQL.
Cobby

3

Aus Ihren Kommentaren geht hervor, dass Sie versuchen, Propel oder Doctrine auszuwählen, um Ihren Bedarf an ORM in einer Legacy-Anwendung zu ersetzen oder zu erfüllen.

Abgesehen davon denke ich, dass es wichtig ist, die Tatsache nicht aus den Augen zu verlieren, dass der Wechsel zu einem der beiden eine große Verbesserung für Ihre Anwendung sein könnte. Es gibt also keine wirklich falsche Antwort.

Daher hängt die von Ihnen gewählte Lösung weitgehend von Ihren Präferenzen ab, basierend auf Ihren Antworten auf die folgenden Fragen:

  1. Welches lässt sich am besten in Ihre aktuelle Lösung integrieren?
  2. Welche API bevorzugen Sie?
  3. Zu welchem ​​würden Sie lieber beitragen? (Patches, Dokumentation, Fehlerberichte usw.)

Ich persönlich würde Doctrine 2 aufgrund seiner Community, Dokumentation und Architektur empfehlen .


1
Ich suche hier allerdings einen Vergleich zwischen ihnen. (Warum macht es was aus, zu dem ich lieber beitragen möchte? Ich möchte zu keinem von ihnen etwas beitragen - ich möchte die Bibliothek benutzen, nicht schreiben!;)). Sie sagen, Doctrine 2 hat eine gute Community, gute Dokumente und gute Architektur - architekturmäßig ist es DataMapper. Was die Dokumente betrifft, bin ich mir nicht sicher, ob ich dem zustimme - beide Projekte scheinen gute Dokumente zu haben. Ich habe nicht viel von einer Community gesehen, die eines der beiden Systeme verwendet. Möchten Sie näher darauf eingehen, was Sie mit diesen Dingen meinen?
Billy ONeal

2
Oh, Sie mögen den Doctrine Doc? Hast du den Propel gelesen? Und ja die Lehre Gemeinschaft ist schön, aber einen Blick auf die ODM - Repository nehmen, sind viele PRs nicht einmal kommentiert noch fusionierte noch abgelehnt ... Blick auf die Propel - Timeline, die Gemeinschaft ist wirklich aktiv;)
William Durand

3

Ich empfehle Ihnen Propel, weil es gut integriert, schnell und leistungsstark ist. Das Generieren von Code ist besser als das Laden von Klassen zur Laufzeit. Es vereinfacht die Debug-Schritte und zeigt Ihnen, was Sie erstellt haben. Der Build-Schritt ist also kein Problem.

Doctrine2 hat keine offiziellen Verhaltensweisen, und das DataMapper-Entwurfsmuster ist cool, aber im wirklichen Leben schwer zu verwenden. Oh und DQL ist ein Schmerz, aber eine abenteuerliche Sprache zu lernen ...

Wenn Sie mit Objekten denken möchten (kein DQL / SQL / was auch immer), wählen Sie Propel.

Doctrine2 ist ein Teil von Symfony2 de facto, aber die Dinge werden sich sehr bald ändern, siehe den letzten Artikel von Fabien Potencier.

Prost, William


Ich habe vor 2 Jahren mit Propel mit symfony1 angefangen und musste dann für symfony2 auf Doctrine2 umsteigen. Gerne wieder bei Propel.Cheers!
Bhanu Krishnan

2

Sie sind beide sehr gut. Es gibt einige Randfälle, in denen man etwas tun oder etwas besseres tun kann als der andere. Wo auch immer ich Probleme hatte, lag es mehr an meinem Unwissen als an etwas, was sie nicht konnten.

Dies bedeutet, dass Dokumentation und Support wichtiger sind als die eigentlichen Fähigkeiten des Codes. Kennen Sie jemanden, der Ihnen bei Problemen helfen kann? Wie gut verstehen Sie sich mit der Dokumentation? Fühlt sich einer von ihnen für Sie "natürlicher" an?


2

Ich entschied mich für Propel 1.63 für eine große ältere MySQL-Anwendung (ca. 200 Tabellen) - die hier genannten Faktoren: IDE-Unterstützung, mit der neue Entwickler sich mit Code-Vervollständigung leicht zurechtfinden können; datenbankübergreifende Schemaunterstützung, Leistung; Bessere native Unterstützung für Aufzählungen und die Verwendung mehrerer Verhaltensweisen. Eigentlich habe ich mit Doctrine angefangen, da dies von Symfony2 am besten unterstützt wurde, aber nachdem Propel die Unterstützung für Symfony (die nächste Plattform, auf die ich irgendwann migrieren werde) erheblich verbessert hatte, wechselte ich aufgrund der besseren Behandlung der oben genannten Probleme. Überhaupt kein Bedauern Propel ist ein entscheidender Gewinner.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.