Click here to Skip to main content
15,916,189 members
Articles / All Topics

Do You Really Need An ORM?

Rate me:
Please Sign up or sign in to vote.
5.00/5 (5 votes)
14 Nov 2011CPOL3 min read 32.4K   9   9
You would save a lot of effort by starting with the simplest thing that works.

An Object-Relational Mapping (ORM) is necessary only when you have:

  1. a domain model, and 
  2. a need to persist this domain model to a Relational Database Management System (RDBMS)

The latter may be a given, especially in web-based scenarios. However, the former is not always so clear-cut.

You have a domain model if you have a collection of fully-fledged classes with both data and behavior.

Object Oriented Design (OOD) is predicated on the tight coupling between an object’s data and the methods that operate on that data. Without the associated behavior, you are left with an anemic domain model. What you have is an object graph with relationships and data that map to the problem domain, but the fine-grained behavior is limited to getters and setters for the data.

Image 1

A simple blog class diagram; note the lack of object behavior

Often, the ‘business logic’ is extracted into a service layer which orchestrates the objects at a much more coarse-grained level.

The UML diagram shown is a very simple blog class diagram. Notice that there are objects, with names matching the nouns in the problem domain. However, there is no behavior on any of the objects. User is missing verbs like Login, CreateCategory, and SubmitComment. Post is missing verbs like SaveDraft and Publish. Comment is missing verbs like Accept and Flag.

These are the fine-grained behaviors that will probably end up rolled into a service layer’s higher-level functionality. There is nothing wrong with this, providing that there is not an ORM sitting between this object graph and persistent storage (as opposed to just serializing the object graph).

As blogs are typically online, it is reasonable to assume that there would be an RDBMS used as the persistent storage. This covers one half of the prerequisites of using an ORM. But there is definitely no need for an ORM here because there is no domain model.

So, what are the alternatives?

Martin Fowler provides a number of alternatives in his book Patterns of Enterprise Application Architecture - under Data Source Architectural Patterns.

Rather than enumerate the high-level patterns that Martin Fowler has already suggested, I’ll jump into technology choices instead. Assuming that the ORM of choice was originally NHibernate, you could just choose a simpler ORM such as Entity Framework. This will certainly make generating the mapping code far simpler than learning NHibernate’s configuration files. But, even that could be argued as overkill.

Perhaps Active Record would be a good fit, but again this is also a suitable alternative when there is behavior inside the objects, thus potentially overkill.

The simplest solution that I would advocate when there is no behavior in the object graph is a Typed DataSet. First of all, a typed dataset can be generated from an existing database and this yields the CRUD operations for all of the tables, as well as locally maintaining referential integrity without having to hit the database again.

Furthermore, if deemed necessary, the messy auto-generated code can be hidden behind neat interfaces for each object by adding a partial definition for each class generated – as long as the properties match the type and name of those generated.

What we are creating with this pattern is merely Data Transfer Objects (DTOs) – which is pretty much what we started with because DTOs are objects without any behavior. We’re just admitting the fact and making design decisions based on that admission.

Perhaps you may think that there will be a future requirement for behavior in your domain model which merely hasn’t yet been fulfilled. Perhaps, but until that day comes, you would save a lot of effort by starting with the simplest thing that works. 


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By
Software Developer (Senior) Nephila Capital Ltd.
Bermuda Bermuda
An experienced .NET developer, currently working for Nephila Capital Ltd. in Bermuda. Author of "Pro WPF and Silverlight MVVM".

Comments and Discussions

GeneralMy vote of 5 Pin
Pablo Aliskevicius21-Nov-11 20:35
Pablo Aliskevicius21-Nov-11 20:35 
GeneralRe: My vote of 5 Pin
garymcleanhall22-Nov-11 7:25
garymcleanhall22-Nov-11 7:25 
GeneralMy vote of 5 Pin
Juy Juka21-Nov-11 18:40
Juy Juka21-Nov-11 18:40 
QuestionNot quite true Pin
FZelle14-Nov-11 23:13
FZelle14-Nov-11 23:13 
You are on the right track, but might have come short.

Yes, a fullblown ORM like NHibernate or EF is an overkill for most of the devs working with small databases, but typed DS is no real solution.
And to fix the shortcommings of the typedDS afterwards is not the right way to do it.

Also you might have the wrong impression why to use an ORM.
It is not only about behavior you implement, it is also about type savety and eas of use.

And if you take a lightweight micro-ORM like PetaPoco or Dapper.NET and combine them with the T4 scripts, you have a very light, typesave and elegant way to deal with databases.
AnswerRe: Not quite true Pin
garymcleanhall15-Nov-11 0:24
garymcleanhall15-Nov-11 0:24 
GeneralRe: Not quite true Pin
FZelle15-Nov-11 2:16
FZelle15-Nov-11 2:16 
GeneralRe: Not quite true Pin
Pablo Aliskevicius21-Nov-11 20:33
Pablo Aliskevicius21-Nov-11 20:33 
SuggestionGood artice to calm down "youth architectors" :) Pin
Thornik8-Aug-11 5:09
Thornik8-Aug-11 5:09 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.