Object Relational Mappers Series - Overview

It's been about 5 years since I last blogged about ORMs (Object Relational Mappers).  You can read that article [[ORM Tools|here]].  At the time my focus was mainly on the performance aspect of why ORMs can be bad.  Since then I've learned quite a bit.  I never bothered to make note of those tidbits of wisdom so I thought it was time for another blog series on ORMs.  In this series I broaden the scope of the posts from just performance to everything the diligent data architect should need to know.  

The posts in this series will focus on these topics:

• [[Object Relational Mappers Series - Overview|Overview...this post]]
• [[Object Relational Mappers Series - Arguments for an ORM]]
• [[Object Relational Mappers Series - The Most Egregious Issues]]
• [[Object Relational Mappers Series - Goofy Syntax]]
• [[Object Relational Mappers Series - More On Proprietary Query Languages]]
• [[Object Relational Mappers Series - Using Proprietary Features of Your RDBMS Incorrectly]]
• [[Object Relational Mappers Series - Entity Navigation vs Entity Query]]
• [[Object Relational Mappers Series - Polymorphism Problems]]
• [[Object Relational Mappers Series - JOINs vs IN Clauses]]
• [[Object Relational Mappers Series - Concurrency and the Non-Updating Update]]
• [[Object Relational Mappers Series - The Caching Conundrum]]
• [[Object Relational Mappers Series - Is Your ORM Eager to be Lazy]]  
• [[Object Relational Mappers Series - The N+1 SELECTs Problem]]
• [[Object Relational Mappers Series - The SELECT * Problem]]
• [[Object Relational Mappers Series - The UnGodly GUID]]
• [[Object Relational Mappers Series - So You Want to Use an ORM Anyway]]

But it might be best to start with a general overview.

What's an ORM?

An Object Relational Mapper links your application code objects to their persistent relational storage.  An ORM can boost productivity, but potentially at the costs of flexibility and performance.  This is a classic ilities problem in my opinion.  Specifically, in the object-oriented programming world we like to think about manipulating objects vs data.  An object generally contains non-scalar data and data in an RDBMS is generally a collection of scalar data elements.  An example in the real world is "an employee can have many phone numbers."  In the database world I might have an EmployeeTable and a ContactInfo table that has a foreign key back to the Employee and each row is a different phone number.  In the OO world I likely simply manipulate an EmployeeObject that has various properties and methods to manipulate individual phone number instances.  Hopefully you can see the impedance mismatch problem here, namely the mapping from the object to the RDBMS is not simple.  ORMs try to bridge the gap by mapping the objects to their relational counterparts.  So, instead of having to write a bunch of custom, hand-crafted SQL in your app to do simple things like INSERT a row in the Employee Table or UPDATE a phone number, we can simply call an ORM method to do it for us.  

IdeaBlade DevForce is an example in the .NET arena, JDO/KODO in the Java world, and Hibernate is an open source ORM tool.  There are many more I have no experience with, but likely they follow the same patterns to a degree.  LINQ is the newest hot tool.  It is MS's ORM tool for the .NET language.  [[LINQ|It's actually a lot more than that too]].  .NET's EF (Entity Framework) is supposedly a more high-powered ORM than LINQ even, and it looks like after only a few years LINQ to SQL is being sunsetted in favor of EF (that alone should be enough to give you second thoughts about using an ORM).  I have no experience, but the fact that MS has two ORM tools makes me wonder when one will be dropped for the other.  Is it really worth developing against LINQ or EF if this is a possibility? 

Next up...[[Object Relational Mappers Series - Arguments for an ORM]]