Ronny’s Blog

Nachdem er letzte Woche mit diesem und diesem Beitrag für einiges an Wirbel gesorgt hat, hat François Zaninotto heute einen Beitrag verfasst, in dem er von der Möglichkeit schreibt, beide Datenbank Mapper (ORM) unter einen Hut zu bringen. Dies will er erreichen, indem er sein sfPropelFinder Plugin zu einem DBFinder Plugin mutieren lässt. Einer der Gründe, die ihn dazu bewegen sind die Vielzahl der Symfony Plugins, die entweder auf Propel oder auf Doctrine setzen.

That means that plugins like sfSimpleForumPlugin, sfSimpleCMSPlugin, or sfGuardPlugin could have one single version working in both ORMs. No more code duplication between a Propel and an Doctrine version, no more time lost to backport modifications from one version to the other. And most important: a larger user base for all plugins, since both Doctrine users and Propel users can use them.

Wenn man es schaffen würde beide ORMs in seinem Plugin zu ermöglichen, wäre auf der einen Seite die Akzeptanz des Plugins sicherlich höher und auf der anderen Seite, müssen man sich als Entwickler weniger Gedanken machen, wie man das nun auf den jeweils eigenen Datenbank Mapper umbiegt.

Ich finde diesen Grundgedanken sehr gut, auch wenn es, wie François selber schreibt, abzusehen ist, dass die jeweiligen ORM-Verfechter davon Abstand nehmen werden wollen.

I also hear voices saying: “Both Doctrine and Propel are abstraction layers. It doesn’t make sense to build a layer to abstract abstraction layers”. Those voices say right, and being abstract for the sake of being abstract is useless and too Java-like for us RAD fans.

Der Ansatz dabei ist folgender:

Er versucht seine sfPropelFinder Klasse die so zu benutzen ist:

$article = sfPropelFinder::from('Article')->
where('Title', 'like', '%foo')->
leftJoin('Author')->
where('Author.Name', 'John Doe')->
orderBy('CreatedAt', 'desc')->
findOne();

und die Doctrine Klassen:

$article = Doctrine_Query::create()->
from('Article a')->
where('a.title like ?', '%foo')->
leftJoin('a.Author u')->
where('u.name = ?', 'John Doe')->
orderby('a.created_at DESC')->
fetchOne();

mit einer eigenen sfDoctrineFinder Klasse:

# Listing 3 - Finding Doctrine objects with sfDoctrineFinder
$article = sfDoctrineFinder::from('Article')->
where('Title', 'like', '%foo')->
leftJoin('Author')->
where('Author.Name', 'John Doe')->
orderBy('CreatedAt', 'desc')->
findOne();

auf einen gemeinsamen Nenner zu bringen, der wie folgt aussieht:

# Listing 4 - Finding Model objects with DbFinder
$article = DbFinder::from('Article')->
where('Title', 'like', '%foo')->
leftJoin('Author')->
where('Author.Name', 'John Doe')->
orderBy('CreatedAt', 'desc')->
findOne();

Der Entwickler nutzt einfach die DBFinder Klasse und brauch sich nicht darum scheren, welcher ORM ihm nun zugrunde liegt. Klar soweit, oder?!

Hierbei handelt es sich um ein klassisches Dev-Pattern (Entwurfsmuster), welches sich dem Fall das (Abstract) Factory Pattern ist.

Die Abstrakte Fabrik (engl. Abstract Factory, Kit) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung und gehört zu der Kategorie der Erzeugungsmuster (Creational Patterns). Es definiert eine Schnittstelle zur Erzeugung einer Familie von Objekten, wobei die konkreten Klassen der zu instanzierenden Objekte dabei nicht näher festgelegt werden. Das Muster ist eines der sogenannten GoF-Muster (siehe Viererbande). (via Wikipedia)

Hier noch ein Video… habs selber nicht komplett gesehen, weil YouTube grad so lahm ist… aber ich wollte es zum auflockern hier auch reinposten.

Popularity: 33% [?]

Werbung: