A user recently asked for good arguments in favor of using Object/Relational Mapping technology:
If you were to motivate [sic] the “pro’s” of why you would use an ORM to management/client, what would the reasons be?
Try and keep one reason per answer so that we can see what gets voted up as the best reasons.
I offered four answers. The first three got the most votes, but my last answer got little interest.
- Speeding development. For example, eliminating repetitive code like mapping query result fields to object members and vice-versa.
- Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don’t have to.
- Supporting OO encapsulation of business rules in your data access layer. You can write (and debug) business rules in your application language of preference, instead of clunky trigger and stored procedure languages.
- Generating boilerplate code for basic CRUD operations (Create, Read, Update, Delete). Some ORM frameworks can inspect database metadata directly, read metadata mapping files, or use declarative class properties.
There are lots of other reasons for and against using ORM frameworks. Generally, I’m not a fan of ORM’s, because their benefits don’t seem to make up for their complexity and tendency to perform slowly. Their chief value is in reducing the time taken in repetitive development tasks.
Hibernate, for example, is about 800,000 lines of code (Java and XML), but it’s complex enough that I doubt it’s easier to learn or to use than SQL. Besides, there seem to be fundamental tasks, such as a simple JOIN that are impossible to do through the entity interface. Please correct me if I’m wrong, but I’ve been searching tutorials and examples and I haven’t found a way to fetch a joined result set from two entities, without writing a custom query in HQL (Hibernate’s abstract version of SQL).
I was also led to a blog by Glenn Block, titled “Ten advantages of an ORM (Object Relational Mapper).” I disagree with Block on several points. He cites some traits of ORMs as advantages where I see them as defects. He also cites features that are not specific to ORMs; they could be achieved with any type of data access library.
update: Upon request, here are some specific comments on Glenn Block’s list of advantages of an ORM:
1. Facilitates implementing the Domain Model pattern
Not necessarily. I can design Domain Model classes containing plain SQL as easily as I can design classes that operate on the database via an ORM layer. Keep in mind that ActiveRecord is not a Domain Model.
2. Huge reduction in code.
Depends. When executing simple CRUD operations against a single table, yes. When executing complex queries, most ORM implementations fail spectacularly compared to the simplicity of using SQL queries.
3. Changes to the object model are made in one place.
This is not a benefit of an ORM. Many people use ORM interfaces inexpertly, so when the database structure changes, they still have to update many places in their application to reflect the change. But instead of redesigning SQL queries, they have to redesign usage of the ORM. There is no net win. They could structure their application using plain SQL queries and still be as likely to achieve the benefit of DRY.
4. Rich query capability.
Absolutely wrong.
5. You can navigate object relationships transparently.
This is definitely a negative rather than a positive. When you want a result set to include rows from dependent tables, do a JOIN. Doing the “lazy-load” approach, executing additional SQL queries internally when you reference columns of related tables, is usually less efficient. Leaving it up to the ORM internals deprives you of the opportunity to decide which solution is better.
6. Data loads are completely configurable …
This is not a benefit of an ORM. It is actually easier to achieve this using plain SQL.
7. Concurrency support.
Again, not a benefit of an ORM.
8. Cache managment.
This has nothing to do with using an ORM. I can cache data using SQL.
9. Transaction management and Isolation.
Also has nothing to do with using an ORM versus a more direct DAL.
10. Key Management.
Ditto.
I’m posting to my blog the questions I’ve answered on StackOverflow, which earned the “Nice Answer” or “Good Answer” badges. This was my answer to “Why Should You Use An ORM?“
