To ORM or Not to ORM. That is the question…

UPDATE:  Thanks for the feedback and comments.  I have adjusted my table below with your recommendations.  I had missed a point or two.

I wanted to do a series on creating an entire project using the EDMX XAF code generation and the SpecFlow BDD Easy Test tools discussed in my earlier posts, but I thought it would be appropriate to start with a simple comparison and reasoning on why I choose to use these tools.

Let’s start by defining the term ORM, or Object-Relational Mapping.  According to Wikipedia it is defined as the following:

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language.

Why should you care?  Basically it allows you to map your business objects in code to their persistence layer behind them. And better yet, why would you want to do this?  Let me outline it in the following points:

  1. Development speed.  No more need to map repetitive tasks query results to object members.  Once the map is created the code is rendered for you.
  2. Persistence portability.  The ORM knows how to map SQL specific syntax for the persistence engine you choose.  It does not matter if it is SQL Server, Oracle and another database of your choosing.
  3. Standard/Boilerplate code is simplified.  The basic CRUD operations are consistent and case use database metadata for basic operations.

So how does this help?  Well, let’s compare some of the ORM tools that I have used and/or researched.  I have been interested in ORM for some time now.  My ORM of choice for a long time was NHibernate and I still believe it has a strong case in some business situations.  However, you have to take business considerations into account and the law of diminishing returns.  Because of these two factors, my recent activity and experience has been around DevExpress eXpress Persistence Objects (XPO). 

The primary reason for this is because they have the DevExpress eXpress Application Framework (XAF) that sits on top of XPO.  With this added value, the data model can be created (either database first of code first) and the Web and Windows client can be created from these maps.  While out of the box they provide some simple list and detail screens, you can verify easily extend and modify these to your liking.  DevExpress has done a tremendous job of providing enough framework while also staying out of the way when you need to extend it.  This sounds worse than it really is.  What I mean by this is that if you choose to follow DevExpress coding style and recommendations, the hooks and extension points provided allow you to do some pretty heavy lifting while also not worrying about the basics.

I have put together a list of the top features that I have used to compare the limited list of ORM’s that I have exposure with.  Again, the biggest selling point in my opinion is that XPO is just a solid as any of the other ORM’s but with the added layer of XAF they become unstoppable.  And then couple that with the EDMX modeling tools and code generation, it becomes a no brainer.

Designer Features Entity Framework NHibernate Fluent w/
Nhibernate
Telerik OpenAccess DevExpress XPO DevExpress XPO/XAF plus Liekhus Tools
Uses XML to map relationships - Yes - - -  
Visual class designer interface Yes - - - - Yes
Management integrated w/ Visual Studio Yes - - Yes - Yes
Supports schema first approach Yes - - Yes - Yes
Supports model first approach Yes - - Yes Yes Yes
Supports code first approach Yes Yes Yes Yes Yes Yes
Attribute driven coding style Yes - Yes - Yes Yes
             

 

I have a very small team and limited resources with a lot of responsibilities.  In order to keep up with our customers, we must rely on tools like these.  We use the EDMX tool so that we can create a visual representation of the applications with our customers.  Second, we rely on the code generation so that we can focus on the business problems at hand and not whether a field is mapped correctly.  This keeps us from requiring as many junior level developers on our team. 

I have also worked on multiple teams where they believed in writing their own “framework”.  In my experiences and opinion this is not the route to take unless you have a team dedicated to supporting just the framework.  Each time that I have worked on custom frameworks, the framework eventually becomes old, out dated and full of “performance” enhancements specific to one or two requirements.  With an ORM, there are a lot smarter people than me working on the bigger issue of persistence and performance.  Again, my recommendation would be to use an available framework and get to working on your business domain problems. 

If your coding is not making money for you, why are you working on it?  Do you really need to be writing query to object member code again and again?

Thanks

Print | posted on Sunday, November 20, 2011 10:00 PM

Feedback

# re: To ORM or Not to ORM. That is the question…

left by Joao Cardoso at 11/21/2011 4:25 AM Gravatar
Entity Framework already supports Code First....

# re: To ORM or Not to ORM. That is the question…

left by Johan at 11/21/2011 4:38 AM Gravatar
Entity Framework with Code First is a Yes:
http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx

# re: To ORM or Not to ORM. That is the question…

left by Patrik at 11/21/2011 5:03 AM Gravatar
Entity Framework supports code first approach.

# re: To ORM or Not to ORM. That is the question…

left by Josh at 11/21/2011 7:53 PM Gravatar
Entity framework also uses xml to map relationships.

# re: To ORM or Not to ORM. That is the question…

left by Sean Hederman at 11/21/2011 10:14 PM Gravatar
Except....Entity Framework is a piece of crud (no pun intended). The designer is buggy and many of the most important properties aren't even surfaced in it so even if it saves correctly; you'll need to make changes to the underlying XML BY HAND every time you resync with the DB.

It's a bad answer to question no-one was asking: "How can I load objects in a manner consistent with the best practices in Java in the 90's?"

Things have moved on in the ORM space, but Microsoft hasn't bothered keeping up.

# re: To ORM or Not to ORM. That is the question…

left by Jag Reehal at 11/22/2011 5:49 AM Gravatar
Patrick,

If you choose to use an ORM it’s important to understand what they’re doing and how they work see ORMs don't kill databases. Developers do - http://www.arrangeactassert.com/orms-dont-kill-databases-developers-do
Post A Comment
Title:
Name:
Email:
Comment:
Verification: