Ich beschäftige mich schon seit sehr sehr langer Zeit mit dem Thema des objektrelationalen Mappings bzw. der Persistenz von Objekten. Einige von euch werden nun sicher nur Bahnhof verstanden haben, aber die meisten von euch werden doch bereits mit diesem Thema zu tun gehabt haben. Es geht dabei um die Abbildung von Objekten der Applikation auf die Datenbank, so wie die dortige Verwaltung und das erneute Laden. Dabei stößt man auf mehrere Probleme.

• Unterschiedliche Realisierung der Abbildung von Relationen
• Überwachung und zentrale Verwaltung von Objekten
• Vermeidung überflüssiger Transaktionen
• Vermeidung von kollidierenden Operationen auf Objekten
• Validierung und Filterung der Daten

Das alles in einer Bibliothek zu beachten und zu lösen, ist eine sehr große Aufgabe. Wie fast immer gibt es hier verschiedene Möglichkeiten diesen Problem zu lösen. Die zwei nennenswertesten sind wohl Active Record, das sicher einigen aus Ruby bekannt ist, und das von Martin Fowler beschriebene DataMapper-Pattern. Während bei Active Record versucht wird die CRUD-Operationen auf einem Objekt direkt an das Objekt zu binden, also in einer gemeinsamen Klasse unterzubringen, wird bei der Implementierung eines DataMappers versucht eine Klasse zu schaffen, die alle Informationen über die Struktur der Datenbank und der Objekte zur Verfügung gestellt bekommt und alle Mapping-Vorgänge vorzunehmen. Das bedeutet, dass Objekte mit Hilfe des Mappers unter Angabe der Domäne geladen, gespeichert und gelöscht werden können.

Einen solchen Mapper implementierte auch Vance Lucas mit dem phpDataMapper, einem recht kompakten und dennoch mächtigen Vertreter. Jedoch hat er das durch Herrn Fowler beschriebene Pattern etwas verändert. Es gibt zwar eine Mapper-Basis-Klasse, von der allerdings nur geerbt wird. Es wird also nicht ein zentraler Mapper, sondern für jedes Model der Business-Schicht ein eigener Mapper angelegt. Das mag sehr aufwendig erscheinen, ist es aber eigentlich nicht, da diesen Objekten nur einige Informationen über die zu ihnen gehörenden Daten und Relationen gegeben werden muss.

Leider wurden aber scheinbar einige Dinge bei der Entwicklung des phpDataMappers nicht beachtet. So konnte ich zum Beispiel keine UnitOfWork-Komponente finden, die sich um die Haltung der Objekte kümmert. Dazu gehört es zu überprüfen ob ein Objekt bereits geladen, verändert oder gelöscht wurde, um unnötige Transaktionen zu vermeiden. Es macht ja zum Beispiel keinen Sinn, ein Objekt was gelöscht werden soll vorher noch einmal zu editieren. Außerdem ist es sehr unpraktisch, wenn ein Objekt mehrmals geladen wird, da sonst konkurrierende Operationen auf der Datenbank ausgeführt werden könnten, da zwei Komponenten an einem Eintrag auf zwei Objekten gearbeitet haben.

Zusammenfassend würde ich dennoch sagen, dass sich ein Blick in den Code und ein paar kleine Tests mit diesem ORMapper (object relational mapper) wirklich lohnen. Und falls es Probleme geben sollte, hilft auch der Entwickler Vance Lucas, ein wirklich netter Mensch gerne weiter.