more con than pro

As a sort of unofficial developer (as opposed to full-time) I am always interested in hearing the opinions of experienced developers. This is kind of not what I want to hear -- not that it isn't good to hear it! I've just invested a good deal of time learning Doctrine 2 and I was just beginning to get that "Aaaahh!" feeling one gets when one finally appreciates the beauty and starts getting the labor-saving rewards from a large, complex library.

My humble opinion is that Doctrine can be really wonderful but you have to know what you're doing -- and what IT is doing. When I first started and saw from the query log that it was running 27 queries just to display a few rows of data, that was a pretty good sign that I was not using it correctly. Back to the documentation, more experimentation, and I was able to tune that up (especially when you add caching, which is very well supported).

It may be that ORM is less useful on the fetch side of things are more useful for write operations. And there is nothing stopping us form foregoing the undesired (arguably, gratutiously complex) Query Language stuff for certain read operations and taking advantage of all that ORM power for the insert/update/delete stuff.

As long as you know what the ORM is doing and it will not cause your application problems, you can enjoy the benefits of using a ORM, especially if it makes you more productive.

yes, that's putting it succintly! what I intended to say in my subject line was that the _article_ was more con than pro, but I am a nevertheless a fan of Doctrine, the one ORM library I have learned.

Actually the original title was do's and don't do's of using ORM tools.

As moderator I changed the title to match better what developers are looking for reasons for using or not using a ORM.

Some ORMs have the problems that Victor mentioned, so even if you use them, you should be aware of the matters.

David, I can say that if the tool you are using fits to your needs, then congratulations - you've found the right one. No matter, be it Doctrine or whatever else. If you master it, it will serve you great.

I cannot think though, of any serious hi-loaded project that used Doctrine because of the introduced overhead and lack of control on the level of SQL.

For 99% of web projects, these matters are not that critical. You can very often optimize performance with caching techniques (and you actually will have to do it - regardless of the ORM layer).

Also, I find the Query-object concept really handy. When it comes to dynamically composing an SQL query - it's way more comfortable to talk to an object that to deal with if/else and string concatenation hell.

Agreed. The object-oriented SELECT thing -- e.g., the one provided by Zend Framework -- is really handy for assembling queries dynamically. The bloat that I was thinking of is the "SELECT Application\Entity\User u..." sort of thing.

In reality assembling queries dynamically is rarely needed. Most of the times you just need to pass values to prepared statements but the base of the query is fixed.

That is why a code generation solution often provides more efficient PHP code.

Other than that, like Victor mentioned, you learned SQL, then you need to learn a new language that seems SQL but it isn't. There should be a benefit to doing that.