In this series I will try to cover some of the ORM anti-patterns I have come across. Most of these issues have huge impact on your project architecture, maintainability, user experience, database and network load. Some could complicate your project to the point of paralysis.

Hopefully this series will help you to avoid some of these issues and to make better decisions when using an ORM.

ORM anti-pattern series

We as developers tend to apply the same techniques to solve every problem thrown at us. We learn a new design pattern and all of a sudden that pattern is all over our codebase. We find a new way of writing code and we apply it wherever we can because we are very excited about it or because it feels like it could simplify our solution.

In the past few years, particularly in .Net space, there has been a lot of excitement about ORMs, and when we get excited about something we overuse it. There are scenarios where using ORM is not a good idea, and there are common ORM anti-patterns that could severely impact the project architecture, maintainability, user experience and database and network load. In this series I will try to cover issues I have come across as well as their solution. In this series I am not going to show you how to use a particular ORM and you may not even see any code. I assume that you know your ORM; however, I will try to provide some links to ORM related patterns for those not familiar with inner workings of one.

Below is the list of articles in no particular order:

Never ever one size fits all and this applies to my solutions explained as part of this series. Think about your problem, your requirements and your constraints, know your choices and make an informed decision.

Are these really anti-patterns or am I over-designing?

I call these anti-patterns only because they are used where they should not be and because I see them used incorrectly very frequently. In other words, some of these patterns are used as one-size-fits-all and are thrown at any and all persistence problems without any thought. I have used and will use some of these patterns in my code if they fit my requirements/context.

This series is about issues I have with these patterns; so I am going to do my best to highlight their issues. That said, I will also try to explain where each pattern fits.

anti-patternsorm
Posted by: Mehdi Khalili
Last revised: 12 Feb, 2011 10:24 PM

Comments

22 Jan, 2012 12:16 PM

I also think ORM is an anti-pattern. It encourages poor relational database design and it isn't compatible with any database design techniques such as ER modeling or Object Role Modeling. You can check out my blog post were I explain this in more depth: http://jonpress.wordpress.com/2012/01/19/mvc-and-object-relational-mapping/

23 Jan, 2012 09:35 AM

Jonthan,

Thanks for your comment. To avoid any confusion, I do not think ORM is an anti-pattern and, on the contrary, I think it is one of the best things that has happened to object oriented languages. I have used NoSQL databases and I think they are awesome and very useful in some cases; but in many cases ORM over a relational database is a much better solution.

That said sometimes ORMs are used in somewhat improper ways which is what I am trying to discuss in this series.

Hank
Hank
19 Apr, 2012 09:24 PM

Totally agree Mehdi, ORM is a horrible choice for database access. ACID goes out the window, because transaction isolation levels are ignored. Very much an anti-pattern.

20 Apr, 2012 08:22 PM

Hank,

ORM is NOT a horrible choice. On the contrary, I think it is one of the best choices for data access in most situations.

You can apply the very same isolation levels using ORM that you can using any other data access technology.

This is not a series about ORM being bad - it is about ORM usage anti-patterns.

blog comments powered by Disqus