Ulf Wendel

SimpleORM statt Propel!

Dieses Posting entstand vor etwa einem Monat. Nachdem jetzt das PHP-Magazin über Propel berichtet hat, konnte ich nicht anders als mal etwas zu nörgeln und den Entwurf doch noch zu posten.

Johann hat mir einen Floh ins Ohr gesetzt. Wie es seine Art ist, bemerkte er beiläufig, daß in PHP ein SimpleORM fehlt. ORM steht für objektrelationales Mapping, Simple spielt auf SimpleXML an. Es gibt viele Ansätze in PHP, die für sich reklamieren ein objektrelationales Mapping zu implementieren. Als ich mit dem Floh zu Jan ging, verwies er mich auf Ruby on Rails und Propel, so wie es seine Art ist erstmal nur Hilfe zur Selbsthilfe zu erteilen. Zwei Tage später fragte die Hamburger PHP-Usergroup nach dem Thema objektrelationales Mapping. Ich wunderte mich, daß sich nicht Markus meldete, um von DB_Object zu schwärmen, das in den Akademie Kursen vollmundig mit objektrelationalem Mapping in Verbindung gebracht wird. Angefixt durch Johann und die PHP-UG, schaute ich kurz auf die existierenden Lösungen und bekam das Gefühl, daß keine Lösung wirklich “simple” ist. Ich verbinde mit “simple”:

  • transparente Persistenz
  • Forward Engineering aus dem Objektmodell heraus
  • Ãœbertragung der Funktionen einer relationalen Abfragesprache an den Objektmanager

Transparente Persistenz sagt im Kern nur, daß ich mich als Programmierer nicht dafür interessiere wie meine Objekte in einer Relationalen Datenbank abgelegt werden. Die Speicherung und Wiederherstellung der Objekte im persistenten Medium, in der Datenbank soll transparent geschehen.

Wer in Objekten denken will, der will sich nicht anhand einer Relationendefinition per Reverse Engineering Objekte erstellen lassen. Die Relationendefinition ist zudem semantisch ärmer als die Objektorientierung und es gibt keinen Grund warum man sich freiwillig beschränken sollte. Letztlich bricht es mit meiner Vorstellung von Einfachheit und Transparenz, wenn im ersten Schritt das Relationenmodell formuliert werden muß, bevor der Objektentwurf beginnt. Es kommt daher nur ein Forward Engineering Ansatz in Frage, der aus einem vorhandenen Objektmodell ein Relationenschemata herleitet. Um die Stärke und Mächtigkeit von PHP beim Prototyping nicht zu verlieren, ist das Relationenmodell nicht aus einem UML-Diagramm oder einer anderen Metabeschreibung herzuleiten, sondern aus existierenden Objekten per Reflektion zu bilden. Aufgrund der wenig deklarativen Natur der PHP-Syntax – insbesonderen der schwachen Typisierung – und der Dynamik von PHP wird es massive Probleme beim Mapping geben, denen oft nur mit generischen Lösungsansätzen begegnet werden kann, welche die Performanz vernachlässigen. Wenn ich andererseits an eine agile Entwicklung mit kurzen Zyklen und Prototypen, Refactoring und Pattern wie DataAccessObjects denke, kriege ich das Gefühl, daß ein “langsames”, aber einfaches SimpleORM durchaus nützlich ist.

Etwas, was ich nicht verlieren will bei der Nutzung von SimpleORM ist die Funktionalität der Abfragesprache SQL. Ich habe mich so sehr an Selektion, Projektion, Umbenennung, Verbund, Vereinigung und die Mengenoperationen Vereinigung, Differenz und Durchschnitt gewöhnt, daß ich sie nicht mehr missen will. Ich kann mich kaum davon lösen, ich habe mich daran gewöhnt. Offensichtlich geht es den Leuten von Propel ähnlich. Dem Objektmanager kann man sogar per SQL-Selektion mitteilen, welche Objekte man will. Bei DB_DataObject finden sich obendrein noch Aggregatbildung und Sortierung in Form von API-Calls. Insgesamt wirken die Propel und die DB_DataObject API auf mich, als wolle man sich gar nicht auf eine einfache, möglicherweise etwas limitierte Abfragesprache einlassen, die sich mehr an der Welt der Objekte orientiert.

Nach einem Abend mit vielen Büchern um mich herum, scheint mir die wirkliche Herausforderung bei der Formulierung einer Abfragesprache zu liegen. Das Mapping von Objekt auf Relation per Forward Engineering ist machbar. Generische Regeln existieren, die nur minimale Einschränkungen mit sich bringen.

Nur es bleibt die zentrale Frage: wann löst sich endlich mal eine der vorhandenen PHP-Lösungen von SQL? SQL ist keine Abfragesprache für Objekte. Außerdem bricht die Verwendung von SQL oder in API-versteckten SQL-Ausdrücken die Maxime der Transparenz. Wann endlich setzt sich mal ein PHP-Anwender hin und schreibt ein SimpleORM? Derjenige, der es wagt, sollte OQL in seine Recherchen mit einbeziehen.

Bitte jetzt nicht sagen, ich solle das selbst schreiben…

Comments are closed.