Click here to Skip to main content
Click here to Skip to main content

Do you really need an ORM?

, 14 Nov 2011
Rate this:
Please Sign up or sign in to vote.
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 an 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.

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. 

License

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

Share

About the Author

garymcleanhall
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 PinmemberPablo Aliskevicius21-Nov-11 20:35 
GeneralRe: My vote of 5 Pinmembergarymcleanhall22-Nov-11 7:25 
GeneralMy vote of 5 PinmemberJuy Juka21-Nov-11 18:40 
QuestionNot quite true PinmemberFZelle14-Nov-11 23:13 
AnswerRe: Not quite true [modified] Pinmembergarymcleanhall15-Nov-11 0:24 
GeneralRe: Not quite true PinmemberFZelle15-Nov-11 2:16 
GeneralRe: Not quite true PinmemberPablo Aliskevicius21-Nov-11 20:33 
SuggestionGood artice to calm down "youth architectors" :) PinmemberMember 30824878-Aug-11 5:09 

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

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

| Advertise | Privacy | Mobile
Web02 | 2.8.140826.1 | Last Updated 14 Nov 2011
Article Copyright 2011 by garymcleanhall
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid