PHP ORMs are all missing transparency

Posted 1 year, 8 months ago at 1:20 am by Alvaro. 0 comments

I have always liked using a domain model to build a system. Most of the time, the easiest way to do that is to use some sort of Object-to-Relational mapping tool. I’ve been using Propel successfully for quite a while but I felt that there had to be a better approach. Later on I got to use hibernate (java orm) and I really liked the way it achieves “transparent” persistence. I’ve also seen similar results with SQLAlchemy (python) and LINQ (.NET) but never with a PHP ORM tool.

This transparency is a huge advantage that Data Mapper pattern has over Active Record implementations.

Although the PHP solutions are all MUCH better than not using an ORM at all, they all seem to have serious issues:

• All of them litter your entities (models) with properties and methods used for mapping and saving the entity to the database. This uses up memory and makes the output of “print_r” or “var_dump” full of stuff you don’t expect there.
• EZPDO (and probably others) doesn’t give you back a a real instance of your entity, instead it gives you some object that maps to it, breaking code that uses “instanceof” or type hints.
• Propel, Doctrine, and all Active Record implementations force your entities to extend from one of their classes, which prevents them from extending anything else. (I know there’s some workarounds for this).
• Propel requires complex criteria objects just to create a simple where clause such as ‘WHERE StatusID = 1 OR StatusID = 2′ (you could do this with Criteria::IN, I just couldn’t come up with a better example).
• They are all very big, which might be ok for a platform that holds its objects in memory across requests, but not PHP which re-instantiates them every time.
• Doctrine, EZPDO, and others encourage the use of their own form of SQL. While it may be handy in certain situations, I’ve only had to change database vendors in the middle of a project once in my career and the queries that are difficult to port are never the ones that an ORM would generate for you. They are usually the custom built ones that take advantage of vendor-specific features.

None of these are necessarily deal breakers, but I thought a new PHP ORM could do a much better job.

A few of months ago I started working on Outlet and a few days ago I released version 0.3. I believe it takes care of all of these issues very cleanly. It is unobtrusive and keeps your entities very clean. It provides just enough abstraction while staying very small, just a handful of classes. You can use regular SQL (call vendor-specific functions if needed) while still abstracting out the actual names of the tables and columns. It also feels very much like PHP which was an important objective.

Please check it out and let me know what you think. Keep in mind that it’s a work in progress and there are a lot of features I still would like to implement. That said, I started using it in some of my projects and I’m VERY pleased with the results.

Website: http://www.outlet-orm.org

It is open source (New BSD License) and I am very interested on user feedback. I set up the following google group (forum/mailing list) for anyone interested in submitting questions, bugs, feature requests, etc:
http://groups.google.com/group/outlet-orm

Alvaro