Left on the Web

DbFinderPlugin: The ORM isn't important anymore

Today I tried the DbFinderPlugin for the first time. I am truely impressed. Using this plugin, it is not necessary anymore to really care about which ORM you pick for your project. It's the thought behind symfony 1.1 taken into the symfony ORM-selection.

One of the most important changes in symfony 1.1 was the creation of the symfony platform, the core of symfony had it's classes completely refactored into a fully decoupled set of classes that could easily be picked or overruled when required. It meant total independence of those classes whenever you would choose to do that. An excellent path to go for symfony, as it gives more control to the developer.

With the ORM, that was not fully possible. You would still have to write your code ORM-specific. For Propel, you'd use the Criteria object to build your query, and for Doctrine, you'd use the (slightly more beautiful) chaining of methods to build a query. But if you'd written code for one, you could not easily change to the other. Even moving from Propel 1.2 to Propel 1.3 would offer some challenges.

Enter the DbFinderPlugin, a plugin written by Francois Zaninotto. This seems to be the ultimate solution in writing code that is portable between the different ORM's. When used consistently throughout a project, switching to another ORM should be as simple as installing and configuring the new ORM plugin, configuring your databases.yml, and that's it. DbFinderPlugin will take care of the rest.

I see two very important advantages for the usage of this plugin:

  • Plugin development - Using DbFinderPlugin, it's now very easy to write plugins that don't care about the ORM you are using. The community will benefit a lot from this, as all plugin authors that use this plugin will now write plugins that are compatible with all ORMs. And the plugin authors will benefit a lot from this as well, since it will make their life a lot easier in writing plugins for all ORMs
  • Project development - You don't really need to think about which ORM you need to use up front. You just start with the default Propel with DbFinderPlugin. Then, as the project advances, you can decide what you prefer: Propel or Doctrine. Or you make a choice at the start of your project, but halfway a technical requirement makes you reconsider that choice: switching should now be very easy. No need to rewrite all your queries anymore.
The only possible downside at this point is that Doctrine is not fully supported yet. Propel 1.2 and Propel 1.3 are fully supported already though, so at least switching to the speed and efficiency of Propel 1.3 is already possible. As Doctrine-support is completed, I see a bright future for this plugin and symfony development in general.
Add comment

Comments

gravatar Anonymous: So you are telling me to use a wrapper over a wrapper? Come on be serious a bit, doctrine and propel are very different from one another however both have considerable speed impact. How fast or how much slower do your code runs with that extra DbFinder? Do you have benchmarks available by any chance?
gravatar yoda: So you are telling me to use a wrapper (db finder) over wrapper (orm) over wrapper (db abstraction). Hack no! Whats wrong with mysql_query?
gravatar left: Yes, I am saying you should use a wrapper around a wrapper around a wrapper. Why? Well:

- maintainability: The DbFinder code is very easy to maintain. New developers will have a very easy time getting into this code.
- portability: It is very easy to switch from one ORM to the other when using DbFinder. Just a matter of configuration.
- extendability: If DbFinder is doing things slightly different from how you want it, just extend it to do what you want.

I don't have benchmarks about this, but really, the focus on optimizing such stuff is negated by the strong caching system that symfony has. If you cache well, the actual queries don't need to be run on every request.

And what is wrong with mysql_query() you ask? Well, for one, by hardcoding the usage of that, you're locking yourself into using mysql. even switching from mysql to mysqli would take quite an amount of time, because you have to go through the code to change the function calls everywhere. With an ORM it is a matter of configuration. 2 seconds are needed to switch your application from using one type of database to the other.
gravatar Raphael: Many thanks, left, and I completely agree to your arguments.
With respect to optimisation of performance, my personal experience on developing complex IT applications is that first one needs to cope with the functionality, and then one has the overview to check at which spots optimisation makes sense, or provides the most performance increase in relation to the effort needed for that. But I think optimisation is a separate topic on it's own.
Regarding the idea of becoming completely independent from ORMs and their versions, there remains the schema.yml issue. Doctrine and Propel have individual syntaxes, or am I wrong (working only with Propel yet)?
Cheers R.

gravatar Evert: I got an alternative for the class, and called it DbPluginFinder.

Since I heard of this plugin, I realized it was a good idea to write a wrapper around these two to provide some compatibility.

Henceforth the way to go is DbPluginFinderFinder, a wrapper around a wrapper around a wrapper. :evil:

Whatever happened to getting the job done :)

Sorry for my sarcasm, but I think this closes in on utter non-sense. I personally haven't been in a situation where I needed to switch the RDBMS at all, and when you get to a scalability point where you might need to, your worries are bigger than re-writing a couple of queries.

Then there's the situation where you'd want to distribute an app and have it run on different setups. Valid situation. But if you get to a point where you cannot even dictate the ORM thats going to be used..

Well we're still talking PHP (keep it simple!!)
© 2004 - 2009 Stefan Koopmanschap + Powered by Symfony, photos powered by Flickr, links powered by Ma.gnolia, Shanghai smilies by Iconbuffet. Feeds: rss / atom. Left on the Web v4.2.3