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
10th Mar, 2009
"It's important that the isValid() check happens before the generate() (as in the example above), as otherwise you'll be checking against a new CAPTCHA and the check will always fail."
You saved my day!!!
thx for that
20th Jun, 2009
I have used both Doctrine and Propel and to be honest I am sick of it. I dumped both Propel and Doctrine. No bad words about the developers; they did a real good job but for new projects I found it extremely hard to work with it. For existing databases they are great, but new projects... pff.. therefore I decided to create an ORM layer focused on 'fresh' projects. It works rather different. It just makes up a database based on your code: zero-config. Just include the file and provide a connection string.. thats it. It just designs a database and changes it to fit your code. Like AI. I am not joking; take a look: http://www.buurtnerd.nl/redbean.htm, please tell me what you think I need some feedback..
3rd Aug, 2009
I did not like doctrine nor propel, since none of them have a solution for a system using procedures on the database. Why do I need ORM if database queries do work great and faster than any ORM?
27th Sep, 2009
ORM's are usefull when your projects are getting bigger and bigger. And you should not expect every developer to be clever enough to write excellent SQL. and also an other fact. ORM tools facilitates DB independency (ie. Change of underlying database is expected to be very easy).
With SQL you have to go to every SQL statement that include DB specific functions and syntax.
29th Oct, 2009
I'm from Java to zend framework to web2.0 projects
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
12th Apr, 2010
Sorry for the late comment.
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
15th Apr, 2010
I agree that it's good if the ORM can be 'plugged in' to the framework in such a way that it gives the user a choice. My point about overhead was that currently if you integrate ZF and Doctrine, you end up with two database classes, two database connections etc. Since Doctrine has to exist as a standalone component there will always be some overlap.
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.
18th Feb, 2011
Hi to all. I have tested each ORM, propel and doctrine and there are a good start point.
I have found a syrius orm (http://code.google.com/p/syrius/) and I think that's is really good and simple ORM for php developers
Comments are closed.