Comparison of Propel and Doctrine (PHP ORM)
One of the symfony contributors has posted a comparison of Propel, Doctrine and the Propel integration plugin for symfony. The article focuses mainly on the syntactical differences between the three.
I've been looking at PHP ORM libraries recently, and have spent quite a bit of time with Doctrine in particular. Both libraries have some clever solutions to some tricky problems, I especially like Doctrine's ingenious way of implementing Rails-like acts_as functionality.
I did look at Propel first, since I believe it's been around longer; but was put off by its syntax and focus on auto-generation of classes (which I have an irrational dislike for). Doctrine is a little more intuitive, and the query syntax is a little closer to the Zend_Db_Select/Statement syntax which I'm a big fan of.
Still, it's sad that PHP frameworks have to rely on external libraries for ORM funcionality, as this seems to add an unnecessary layer of overhead for something so fundamental to web application development. The experience has given me a new found respect for Rails' ActiveRecord implementation, and I hope that this is an area that will improve in ZF in the future. Zend have hinted that they'd like to do a proper ActiveRecord implementation post PHP 5.3, it would also be nice to see some components to aid integration with the existing libraries (Zend_Doctrine / Zend_Propel), although these would be fairly mammoth tasks.
Tags:
Comments
16:46, on 10/3/2009
You saved my day!!!
thx for that
23:26, on 20/6/2009
15:52, on 3/8/2009
22:00, on 27/9/2009
With SQL you have to go to every SQL statement that include DB specific functions and syntax.
10:03, on 29/10/2009
I think it's normal framework focus on what they are good, mvc
they have to make easy integration with others components, like ORM
like in Java we use hibernate
so I can use the best in MVC and the best in ORM (I'll try doctrine after be tired of zend_db and begin making simple data rowset class)
so I think zend would have to develop easy integration with others ORM so we have easy choices
02:00, on 12/4/2010
I appreciate your post, although I don't quite get your point about Rail's active record and creating more overhead for the ORM to be separated out from the framework.
I believe the ORM should be separated more from the framework, there is only an increase in overhead if the ORM provide features that already exist in the framework. Afterall MERB having its ORM separated delivered far better performance than Rails, (You could use Data Mapper or Active Record) and in the end encouraged Rails to head for a far more de-coupled approach.
Most Java frameworks also do not bind you to any kind of ORM and don't even include one in the box.
I believe that ORM should be a choice and binding me to one can be frustrating (I am fighting that battle in CakePHP) I would much rather be able to use Doctrine. That is why I am still very pro Code Igniter(even if testing isn't prioritized - which it should be!) as it is flexible enough and light enough to let you decide what features you do and don't need. I am happy that I can easily use either Propel's models or Doctrines, or even use crappy Code Igniter ones - which is good enough for very simple apps.
Cheers
Richard
13:07, on 15/4/2010
However it seems that the ZF team are going to be integrating with Doctrine 2 for ZF 2.0. With cooperation from the Doctrine side it should be possible to remove most of this overlap, and I'm looking forward to seeing the results.
11:03, on 18/2/2011
15:07, on 3/2/2012
Add Comment