Ten advantages of an ORM (Object Relational Mapper)

Updated,  

Here's a list of ten reasons why you should consider an ORM tool. Now not all ORMs are created equal, but these are key features that a first class ORM will handle for you. 

1. Facilitates implementing the Domain Model pattern (Thanks Udi). This one reason supercedes all others. In short using this pattern means that you model entities based on real business concepts rather than based on your database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

2. Huge reduction in code. ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

3. Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

4. Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

5. Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a PO and you want to access it's Customer, you can simply access PO.Customer and the ORM will take care of loading the data for you without any effort on your part.

6. Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of POs without any of it's child / related objects, while in other scenarious you can specify to load a PO, with all it's child LineItems, etc.

7. Concurrency support. Support for multiple users updating the same data simultaneously.

8. Cache managment. Entities are cached in memory thereby reducing load on the database.

9. Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

10. Key Management. Identifiers and surrogate keys are automatically propogated and managed.

Please feel free to add your additional via the comments....

• Anonymous
  October 27, 2006
  ORM = Object Role Modeling. But that's just nitpicking :) There is one main reason to use an object/relational mapper, and that is to implement the Domain Model pattern. I've written about this before here: http://udidahan.weblogs.us/archives/036972.html All the above features lack the context of the model that needs them. The HUGE issue of performance that is often brought up by O/R mapping detractors usually results in a "denormalization" of the model. It's important to keep our eye on the ball, rather than be dazzled by all sorts of technologies.

• Anonymous
  October 28, 2006
  I agree with you that OR/M is definately the primary facilitator for driving domain design.Just as a disclaimier I said these are 'Ten Reasons', not 'The Ten Reasons' ;) My goal here was to enumerate many of the services an ORM provides for developers, that they would otherwise need to implement themselves.

• Anonymous
  December 17, 2008
  This is very useful post. I got more information about the ORM concept. Can you send me the cache management information?

• Anonymous
  January 15, 2009
  How do ORM's facilitate transaction isolation? AFAIK, the only RDBMS that supports multiple transactions per connection is Firebird (aka InterBase), and even then it isn't surfaced through most programming interfaces. Otherwise, you need multiple database connections if you want to transactions to be part of object state.