Propel vs. Doctrine #1

Speziell, wenn man ein neues Symfony-Projekt anfängt, kommt schnell die Frage auf: Nehme ich Propel oder Doctrine für das Object-Relational Mapping (ORM)? Seit Symfony 1.1 ist Propel nicht mehr Pflicht und auch Doctrine kann problemlos genutzt werden. Da aber beide inkompatibel zueinander sind und das wohl auch immer so bleiben wird, muss man eine Entscheidung treffen.

Ich habe mich noch nicht intensiv mit Doctrine auseinander gesetzt, aber ein paar der Features sind verdammt interessant, so dass ich in nächster Zeit mal einen genaueren Blick darauf werfen werde:

• Geschwindigkeit: Seit Propel 1.3 auch auf PDO aufsetzt, ist dies kein Kriterium mehr und Propel 1.3 scheint sogar die Nase knapp vorn zu haben, wenn es um Geschwindigkeit geht.
• Behaviors: Ein geiles Feature. Von Propel kennt man es im Zusammenspiel mit Symfony schon, dass z.B. created_at Zeilen automatisch gepflegt werden. Mit Behaviors hat Doctrine etwas ähnliches an Board, allerdings noch weitaus mächtiger. Definiere ich eine Spalte als Sluggable, wird mir automatisch dafür ein Slug(*) erzeugt. Damit entfällt viel Code, den ich sonst selber schreiben müsste. Das Versionable-Behavior ermöglich es von einer Zeile bzw. einem Objekt mehrere Versionen in der Datenbank zu verwalten. Damit lässt sich ganz einfach und unkompliziert eine Versionsverwaltung aufbauen. Noch ein paar weitere Behaviors runden das Ganze ab.
• Memcache-Driver: Geplant ist ein ähnliches Feature auch für Propel 2.0. Aber Doctrine bringt es schon mit – die Möglichkeit Objekte nicht nur in eine Datenbank zu pressen, sondern auch in einen Cache (bzw. Memcache). Für verteilte Anwendungen mit mehreren Servern bzw. einem Projekt mit Datenbankreplikationen ein Traum!
• Magic Finders: Wie oft ist die erste Handlung, nach dem generieren der Propel-Objekte, angepasste Methoden für die xxxPeer-Klasse zu schreiben, für Fälle bei denen Objekte nicht nur per Primary Key aus der Datenbank geholt werden sollen. Doctrine bietet mit den Magic Finders eine ganze Reihe von Möglichkeiten, das schnell zu bewerkstelligen.
• Inheritance: Das Feature gefällt mir verdammt gut. Vererbung! Möchte man zum Beispiel auf seiner Seite ein Gästebuch und an anderer Stelle Kommentare haben, so haben beide im Grunde die gleiche Basis: Eine Tabelle in die beispielsweise Name, E-Mail, Homepage und Text des Autors gespeichert werden. Aber jeweils beide, Gästebuch-Eintrag und Kommentar, haben eventuell noch zusätzliche, unterschiedliche Felder. Mit Doctrine ist es möglich eine gemeinsame Basis-Tabelle zu definieren und darauf aufbauend weitere Tabellen, die die Eigenschaft der Basis-Tabelle dann in einem Objekt vereinen. Das wird eins der ersten Features sein, die ich unbedingt mal ausprobieren möchte.
• DQL: Doctrine kommt mit einer mächtigen Sprache für Queries daher: DQL. Gerade bei etwas umfangreicheren, verschachtelten Abfragen wird das bauen eines Criteria/Criterion-Objekts mit Propel etwas umständlich. Mit DQL soll dies weitaus leichter sein.

Soviel zunächst zu den, für mich wichtigen, Vorteilen von Doctrine. Es sind auf jedenfall wie gesagt genug, so dass ich mich mal intensiver mit Doctrine beschäftigen möchte. Mir sind auch ein paar Nachteile aufgefallen, bei denen ich noch genauer nachsehen muss, ob es denn welche sind. Aber diese werde ich in einem weiteren Artikel verbloggen.

Auch Propel plant einige geniale Features für die Version 2.0 – so z.B. die angesprochene Möglichkeit Objekte zu cachen – nur ist es halt noch in Entwicklung.

* Slug: Ein Slug ist z.B. für eine URL angepasster Titel eines Artikels, damit dieser lesbar bleibt und in der URL verwendet werden kann. Außerdem muss ein Slug immer eindeutig sein, im Gegensatz allerdings zum Titel eines Artikels, der häufiger vorkommen kann.