DaveWentzel.com            All Things Data

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 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:

 

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.  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...nodetitle

Add new comment