For what it’s worth guys, here is my perspective of the situation, since I am the most experienced OO developer on the team, and was the one that took the initiative to experiment with ORMs, and have had experience with ORMs in the past:
- Propel is much more flexible and efficient than EZPDO. I evaluated all of the PHP ORMs listed at wikipedia, and my evaluations were very similar in outcome to the one in the article, though EZPDO has indeed improved greatly over the past few months. I prefer the overall architecture and source code of Propel though, and I chose it because I felt comfortable about using it and, more importantly, about being able to customize and optimize it for my needs (or really, the needs of MODx).
- Though it won’t be supported going forward, there is a PHP 4 generator and run-time from Propel, so it is possible we could port most of the features down to a PHP 4 version at some point, if so desired. The only features that would be hard to put back into PHP 4 are the runtime class generation features I plan on adding.
- Propel has the added benefits of:
* Dynamic SQL script generation for all platforms; EZPDO generates tables on demand, which is a nice feature, required manual maintenance of the tables. EZPDO’s model is similar to EJBs in the J2EE world, which equals no flexibility in defining your relational model, and is generally a code maintenance nightmare.
* Unit testing is already exemplified in the Propel project; it includes several sample unit tests in the sample project and this can be translated into an instant unit testing framework for MODx.
* Class generation from templates means that adding new methods or members to a base class (e.g. so all existing implementation classes inherit the additions) is as simple as customizing the template and re-generating the classes. The stubs are left alone with our custom MODx business logic, and the base classes are regenerated with the new methods/members. This means I could add event handling or permissions, or versioning capabilities to every object in our model within a matter of minutes, once proper design patterns are identified for such features. Generation of our entire class model takes about 3 to 5 seconds in Propel.
* Self contained runtime; once the generation/build process is left behind, the only dependencies for Propel are DOM support in PHP (very common, only a few binary distributions do not include DOM automatically, most notably, Debian) and the Creole runtime (which gives us two different access models to the DB, using Creole’s default, JDBC-style layer, or the optional Jargon layer that emulates ADO-style datasets. The others all depend on Pear::DB, (though EZPDO does now work with ADOdb) or another external dependency that may or may not be available to a specific deployment environment.
There are plenty of other reasons I believe Propel is the right choice here; but to me, all the ORMs would have issues when integrating with our project. Propel provided the best path to reverse engineer our current system to transform it into fully functional object model; it took me less than two weeks to do this with no previous experience. Imagine what we can accomplish with it moving forward, as everyone becomes more familiar with the new infrastructure.
BTW, I am currently evaluating profiling tools that might be able to be incorporated into the build system as well, so in addition to unit testing, we can have automatic performance benchmarks as part of every build.
MODX Staff
