Ja, ich denke, die Schwierigkeit sind die zahlreichen Konzepte, die auf einmal gelernt werden oder bereits bekannt sein müssen. Namespaces, ein gerüttelt Maß OOP, Entities und zugehöriges dateiübergreifendes Mapping, Mapping-Driver-Syntax (sei es Yaml, XML oder Annotations) und „Meta“-Datentypen, DQL (das ist *nicht* SQL), generell relationale Datenbankkonzepte, … Das ist nicht wenig. Die Doku von Doctrine ist deshalb leider auch nicht die einfachste, weil eben OOP und die relationalen Datenbankkonzepte vorausgesetzt werden.
Ich habe gestern überlegt, ob ich noch weitere Erklärungen hinzufügen soll, mich dann aber dagegen entschieden, weil ich nicht wüsste, wo man anfangen sollte. Mir erschien es aber sinnvoll, zumindest zu zeigen, wie Doctrine in einem Real-World-Beispiel überhaupt mal zum Laufen gebracht werden kann. Normalerweise werfen wir ja nur den Namen in den Raum, was die Einstiegshürde nicht eben verringert.
Vielleicht doch ein, zwei Sätze zu meinem Beispiel:
Der meiste Code hat mit Doctrine eigentlich nichts zu tun, sondern ist ganz normale PHP-Formularverarbeitung für ein Gästebuch.
$entityManager = initializeOrm($conn); ist das, was normalerweise die Verbindungsfunktion des Datenbank-Adapters ist,
$entityManager ist gewissermaßen das, was sonst die Instanz der Datenbankklasse ist. Die Funktionen
getEntries und
addEntry könnten ebenfalls für jeden anderen DB-Adapter so geschrieben werden.
Was sicher abschrecken könnte, ist ein Dateinamen-Monster wie
org.example.Guestbook.Entities.Entry.dcm.yml. Die Bezeichnung ist ein wenig meinem Ordnungswahn geschuldet. Ich bin ein Fan von „an URLs gebundene“ Namespaces (wie in Java verbreitet). Jeder kann „seinen“ Namespace zum Beispiel „Foo“ nennen, was dann trotz allem noch immer zu Benennungskonflikten führen kann. Aber einen Namespace „org\example“ zu nennen, ergibt im Grunde nur dann Sinn, wenn man der Inhaber dieser Domain ist. (Bin ich zwar nicht, aber ist ja auch bloß ein Beispiel.) Wer es nicht so genau nimmt, kann dort definitiv einige Verschachtelungsebenen einsparen. Doctrine selbst erwartet dann, dass diese Yaml-„Entity-Mapping“-Datei dem voll qualifizierten Klassennamen der entsprechenden PHP-Entity-Klasse entspricht, welcher in diesem Fall nunmal
org\example\Guestbook\Entities\Entry lautet.
Foo\Entry oder auch nur
Entry wäre bei entsprechend abweichender Namespace-Nutzung völlig äquivalent, was Doctrine betrifft.
Wie die einzelnen Dateien zusammengehören, wird übrigens hier recht gut erklärt:
-
Getting Started — Doctrine 2 ORM v2.0.0 documentation
Das dort behandelte Beispielprojekt (Bugtracker) ist allerdings eine Ecke komplizierter als mein Gästebuch mit nur einer Tabelle. Als Einstiegspunkt ist dieses Tutorial aber genau richtig.
btw. spl_autoload_register(); reicht aus, wenn die Namespaces der Ordnerstruktur entsprechen.
Das wäre schön, aber wenn ich richtig gelesen/getestet habe, scheint der Standard-SPL-Autoloader alle Klassennamen und somit Pfade in Kleinbuchstaben umzuwandeln. Das funktioniert dann zumindest nicht unter Linux. Oder übersehe ich was?