Square peg in a round Hole

After lots of year working with NHibernate I started to think that probably the whole concept of ORM can be considered an Antipattern. Some people prefer a “classic” approach to the problem, data is the key concept and most of the logic is inside a storage based on Relational Model.

Is this wrong?

Absolutely not, after all, for many years this was the preferred way to structure your application, and it worked quite well, but after OOP has come to life, a lot of people started appreciating this new paradigm of programming and started to think in terms of “objects” instead of “data”.

This is a radical shift, because if you really possess “object thinking”, you tend to subdivide the problem in objects that  have methods instead that in table that have relations. This lead to an obvious problem, since we need to store the data somewhere and since we already have good Relational Database Engine, the simplest solution is finding a way to save Objects in Relational Storage system and an ORM is the answer.

But after years of ORM the initial enthusiasm is completely passed away and I start believing that I’m forcing a square peg in a round hole.

Since most programmers started to work in terms of data and relations (after all university taught us to think in this way), using an ORM lead usually to highly anemic domain and tend to lead people of thinking in term of objects that have state (properties) and relations with other objects instead of object that have methods and communicates with other objects (with events).

If you start designing your entities from their state (properties) it could be the sign that you moved from “tables with relations and stored procedures that operates on tables” to “objects with relations and services that operates on objects”, and you need to realize that the situation is not changed very much.

When people start to have problems with Session duration, Lazy Loading, eager fetching (or other issue related to ORM), is the sign that the square peg is not fitting in the round hole and the ORM becomes the Hammer that forces it down (usually bringing some pain with it).

This means that if you want to do OOP you should move everything to NoSql?

Absolutely not, because sometimes you will probably find yourself forcing a round peg in a square hole :). I’m starting to think that in a real, big, complex OOP project, you need to have both type of storage: Relational and Object based. This will give you  round holes and the square holes, so you can put each peg in the right place.

At least until some new technology comes to life that bring us a new Hexagonal Peg :) that will need an Hexagonal shaped data storage Smile.

Gian Maria.

Published by

Ricci Gian Maria

.Net programmer, User group and community enthusiast, programmer - aspiring architect - and guitar player :). Visual Studio ALM MVP

4 thoughts on “Square peg in a round Hole”

  1. It is a really interesting topic and interesting point of discussion but dear Alk I have to disagree with your point of you.
    I personally believe that when you reach a point in your design where the Domain try to adapt itself to the O/RM and when you design agnostic domains that simply represents the Database structure in an OOP form, you are going down to the wrong path.
    DDD should be used before moving on the Database side and should not be affected by the database structure, this is the first point.
    The O/RM should be considered only the tool to map a Domain to a Legacy or non Legacy database schema, nothing more nothing less.
    Unfortunately, I have to agree with you, many times we go down to the wrong path of having Domain + O/RM acting like a agnostic relational OOP container …

  2. You are right, if you are able to use the ORM just as a tool to save your object to a Relational Model, if you do OOP first, without caring about your persistence layer, the ORM is a good tool, but the question is: when is time to save object somewhere, a NoSql (like Raven) is the best choice, leaving the Relational model for reports, or for views (CQRS).

    I found that it is easier abusing an ORM respect “using” it. :)

  3. Oh yes … For example, where I work I have created a sort of toolkit where you have the Unit of Work, the Repository and the Service; plus you have domains with domain services/events.
    For some people in the team is easier to abuse the O/RM and play in the wrong way with the ISession, by changing in this way the scope of the Domain itself.

  4. This is exactly where I’ve ended up. About 90% of my work is now in MongoDB. However I do have one project where I’m tracking lab data for food quality assurance. There is a very complicated permissions model around viewing/entering quality measurements, so I persist that domain model in a doc db. But the raw measurements themselves are getting queried all different which ways so I put those in SQL server since it’s very tabular data with a well formed structure.

Leave a Reply

Your email address will not be published.