My highlights from OrmHate:
The charges against them can be summarized in that they are complex, and provide only a leaky abstraction over a relational data store. Their complexity implies a grueling learning curve and often systems using an ORM perform badly – often due to naive interactions with the underlying database.
I think that if you’re going to dump on something in the way many people do about ORMs, you have to state the alternative. What do you do instead of an ORM? The cheap shots I usually hear ignore this, because this is where it gets messy. Basically it boils down to two strategies, solve the problem differently (and better), or avoid the problem. Both of these have significant flaws.
This is where the criticism comes that ORM is a leaky abstraction. This is true, but isn’t necessarily a reason to avoid them. Mapping to a relational database involves lots of repetitive, boiler-plate code. A framework that allows me to avoid 80% of that is worthwhile even if it is only 80%. The problem is in me for pretending it’s 100% when it isn’t. David Heinemeier Hansson, of Active Record fame, has always argued that if you are writing an application backed by a relational database you should damn well know how a relational database works. Active Record is designed with that in mind, it takes care of boring stuff, but provides manholes so you can get down with the SQL when you have to. That’s a far better approach to thinking about the role an ORM should play.
I’m guilty of trash-talking ORMs but I also am a huge fan of ActiveRecord. I appreciate Martin Fowler’s ability to articulate the advantages and trade-offs of the ORM and also the other approaches.
