Objektpersistenz über ORM

Die Speicherung von Daten erscheint immer mehr das hauptsächliche Augenmerk zu sein. (Neben dem Ajax / Javascript-geblinke). Ich möchte hier, in aller Kürze, einen Ansatz vorstellen, den ich, mal wieder, aus der Python Welt mitbringe. Wir PHP’ler kennen die ORM’s als Active Record Patterns, bzw. als Table Data Gateways. Es sind also die typischen Schritte…

1. Hole Objekt nach Tabellennamen (evtl. in abgewandelter Form)
2. $objekt->where(‚bedingung=123‘);
3. $objekt->load();
4. $objekt->setFoo(15);
5. $objekt->setBar(42);
6. $objekt->save();
7. unset($objekt);

Das sind meines Erachtens nach die mantraartigen Schritte der Arbeit mit einem std. PHP ORM.

Aus der Python Welt habe ich heute mal SQLObject mitgebracht. SQLObject vollzieht hier einen etwas anderen Ansatz (wenn auch nicht umbedingt neuen Ansatz), um eine Datenpersistenz zu erreichen. In Python gibt es, so wie in PHP auch, Magic Methods. Diese fangen den Zugriff auf Member einer Klasse ab und schleusen ihn durch eine Methode. Auf Grund der Möglichkeit den Zugriff auf einen Member zu „tracken“, kann nun der Zustand der Klasse bestimmt werden. Hier gibt es nun zwei Ansätze mit dieser Zustandsänderung umzugehen:

Ansatz 1: Direct Save

Beim direkten Speichern wird beim ändern des Members der Klasse sofort für die Persistierung gesorgt. Im Falle einen ORM wäre das ein INSERT oder UPDATE Statement an die Datenbank (oder eine gekapselte Methode, die jedoch nichts anderen vollbringen würde). Hier ist der Entwickler allerdings angehalten seine Hilfsvariabeln sauber einzusetzen, da jede änderung am Zustand der Klasse eine Query nach sich zieht! Der klare Vorteil dieser Lösung ist die implizite Persistenz des Instanzzustandes.

Ansatz 2: Die Transaktion

Beim erstellen der Instanz mit dem definierten Anfangszustand wird eine Transaktion auf Applikationsseite gestartet. Alle änderungen laufen in einen Transaktionspuffer.Es können „Soft-Rollback“ – Punkte definiert werden, zu denen während des Scriptablaufes zurück gesprungen werden kann (z. B. im Falle einer Exception). Mit dem Destruktor der Klasse wird schlussendlich der Commit automatisch aufgerufen, sollte dieser nicht vorher erfolgt sein. Ein manueller Commit startet jedoch automatisch eine neue Transaktion, so dass über die gesamte Scriptlaufzeit, theoretisch, mit ein und der selben Instanz gearbeitet werden kann.

Diese beiden Ansätze habe ich bisher in keinem PHP ORM gefunden. Wenn jemand also etwas derartiges kennt, bitte ich um Kommentare!