laszlokorte

Hallo zusammen,

ich würde gerne das ORM vorstellen, was ich in der zweiten Hälfte des letzten Jahres entwickelt, dann aus Zeitmangel erstmal auf Eis gelegt und nun doch mal auf Github gepusht habe.
ich habe keinen Foren-Bereich gefunden, in das besser rein passen würde.
Falls ich hier falsch bin, einfach verschieben.

https://github.com/laszlokorte/Dataphant

Im Prinzip steht alles wichtige in der Readme Datei (und in der demo.php). Ansonsten ist die Dokumentation leider noch sehr bescheiden.

Eines meiner lieblings-Features ist das Smart-Eager-Loading. Damit wird dafür gesorgt, dass die Query-Anzahl nicht exponentiell, sondern linear steigt, wenn man Queries in For-Schleifen schachtelt.
An Ruby's Datamapper hat mir das schon sehr gefallen, wobei es dort nur bei einer Verschachtelung von bis zu zwei Schleifen funktioniert hat. Ich habe da noch einiges weitergebastelt, sodass eine beliebige Tiefe an Verschachtelung unterstützt wird.

Evtl gefällt es ja jemandem und vielleicht hat ja jemand interesse daran, es weiter zu entwickeln, weiter zu testen, zu dokumentieren oder sonst was mit anzustellen.
Pull-Requests sind herzlich willkommen.

Ich würde mich auch über Feedback freuen.

Falls es interessiert noch etwas zu der Entstehungsgeschichte:

Das ganze ist daraus entstanden, dass ich ein ORM in Php brauchte, mich die beien großen Doctrine und Propel aber absolut nicht ansprachen, bzw meine Erwartungen und Anforderungen an die Bequemlichkeit, die nach langem Arbeiten mit Datamapper und ActiveRecord in Ruby recht hoch waren, nicht erfüllten. (Nicht die Design-Patterns, sondern die gleichnamigen Libraries in Ruby)

Da ich eigentlich sowieso weg von Php wollte, hatte ich auch nicht lange weitergesucht, sondern schon aufgegeben, dass es überhaupt möglich ist, mit dem in Php zugrundeliegenden Objekt-Modell etwas zu bauen, was dem Ruby Datamapper nahe kommt.

Was mich dann geritten hat, weiss ich nicht mehr, allerdings habe ich angefangen die Datamapper-Library in Php nachzubauen. Relativ schnell war einerseits klar, dass ich vieles anders umsetzen musste, weil das statische Klassenmodell von Php einiges, was in Ruby an der Tagesordnung steht, nicht erlaubt. Nachdem irgendwann die ersten Queries funktionierten und sogar einige Features besser funktionierten als im Ruby-Datamapper, hab ich immer weiter und weiter gebastelt, obwohl ich an tausend anderen Stellen immer wieder riesige Kompromisse eingehen musste.

Als das ganze dann so gut wie fertig war und sich auch schon richtig gut benutzen liess, hatte ich nicht mehr so viel Zeit weiter zu machen. Die Motivation weiter zu machen ging stetig gegen Null, bis ich das ganze bei Seite legte und eigentlich schon einstampfen wollte.

Nun musste ich aber vor ein paar Wochen wieder mit Doctrine arbeiten und da wurde mir klar, wie viel spaßiger es war mit meinem ORM Queries zu bauen und wie nervig es ist DQL-zeug schreiben und sich um den ganzen scheiss wie Query senden, Daten fetchen und so weiter kümmern zu müssen.

Daher habe ich mir jetzt doch noch mal ein Herz genommen, mein ORM ein wenig aufgeräumt, ihm den Namen Dataphant verliehen und auf Github gepusht.

Mister Ad

nikosch

Werd ich mir bestimmt mal näher ansehen. Schade nur, dass gefühlt so viel static verwendet wird. Ist IMHO unnötig.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

laszlokorte

Das static Zeug gefällt mir auch nicht, ist aber anfangs unter dem Fokus auf einfache Query-Konstruktion entstanden. Müsste man, wie es auch schon auf der Todo steht, in ein ModelDefinition-Objekt auslagern.

Die static-Syntax, also dass man User::nickname() und User::defineProperty() aufrufen kann, ist aber beabsichtigt, da ich auf keinen Fall auf so Zeug wie Annotations zurückgreifen will, aber es möglich sein soll, nur eine Klasse pro Model zu benutzen und nicht wie z.B. in Doctrine in Repository, Entity und Manager aufzuteilen zu müssen.

Da es mit Doctrine u.Ä. ja schon im Java-Stil absolut sauber implementierte Systeme gibt, habe ich extra an einigen Stellen ein Auge zugedrückt, um die DSL zu vereinfachen.

agrajag

Sieht auf den ersten Blick ganz cool aus. Man sieht aufjedenfall, dass es von DataMapper /ActiveRecord inspieriert ist
Das mit den statischen Aufrufen wie User::defineProperty() finde ich eigentlich ziemlcih elegant gelöst und wüsste nicht wie es in PHP schöner - aber gleich einfach - geht.
Sowas:
Group::hasAndBelongsToMany('comments', array('class' => 'Comment', 'through' => 'users'));
ziehe ich jedenfalls allemal irgendwelchem Geraffen mit OneToMany und ManyToOne Annotations vor.
Cool gemacht!

Ich würde die Doku aber definitiv noch etwas pimpen um zu zeigen was es alles kann. Vielleicht auch ein kleines Kapitel für Ruby Umsteiger á la "so geht's in ActiveRecord und so geht's mit Dataphant).

__________________
Today you...Tomorrow me.

laszlokorte

@agrjag: Freut mich, dass es dir gefällt. Sobald ich zeit habe, werde ich auf jeden Fall noch an einer besseren Dokumentation arbeiten.

Die Idee mit dem Umsteiger-Guide finde ich gut, auch wenn ich nicht mit vielen Ruby->Php Umsteigern rechne

agrajag

Umsteiger wahrscheinlich nicht. Aber Leute die was mit PHP machen (müssen), ActiveRecord kennen und deshalb von Doctrine und Co. frustriert sind

__________________
Today you...Tomorrow me.

dr.e.

Sieht auf den ersten Blick nicht schlecht aus. Was mich persönlich stört ist die Definition von Daten-Objekten im Code (Attribute, ...) und die vielen statischen Verwendungen. Letzteres ist hinsichtlich der Testbarkeit nicht Vorteilhaft.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

laszlokorte

Meinst du etwa, dass Modell-Attribute und -Relationen in php statt in einer Config-Datei definiert werden?

xm22

Denke ich auch. Ich mag es auch eher weniger, die ganze Config in Form von Code schreiben zu müssen, statt z. B. das Ganze über ein Array konfigurieren zu können.

lcrash

Vorteil von PHP-Code gegenüber YAML, Ini, XML etc. ist, dass er schneller ist. Was nicht heißt, dass man nicht aus solchen Dateien eine foobar.php.dist zaubern kann.