I had a very stimulating and interessting discussion with a colleague about ORM and its pros and cons. In my opinion, an ORM is useful only in the rarest cases. At least in my experience.

But I don't want to list my own arguments at this time. So I ask you, what do you think about ORM? What are the pros and the cons?


8 Answers 8


There's a is a fairly large and varied set of conceptual and technical difficulties when trying to approach a relational database from an object oriented angle. These difficulties are collectively known as object-relational impedance mismatch and the related Wikipedia article is extremely informative. The article identifies quite a few, I don't see any sensible way of describing them here. Just to give you a general idea, they are catalogued as:

  • Mismatches
    • Object-oriented concepts
    • Data type differences
    • Structural and integrity differences
    • Manipulative differences
    • Transactional differences
  • Solving impedance mismatch
    • Minimization
    • Alternative architectures
    • Compensation
  • Contention
  • Philosophical differences

I think if you take the time to read the article you'll understand that the fact that ORM is sometimes described as an anti-pattern is in fact inevitable. The two domains are so different that any approach to treat one as the other is by default an anti-pattern, in the sense that an anti-pattern is a pattern that goes against the philosophy of a domain.

But I don't think the term should apply to anything that essentially acts as a bridge between two vastly different domains. Labelling a pattern as anti-pattern makes sense only within its domain. So the question of whether it's an anti-pattern or not is irrelevant.

But is it useful? Yes ORM is one of the most useful anti-patterns out there. You will understand why only if you find yourself in a practical situation where you'll have to swap databases in a project. Or even upgrade to another version of the same database. ORM is one of those things, that you only fully understand when you actually need them.

Off course, as everything useful, ORM is highly prone to abuse. If you think it somehow replaces the need to know everything about the database you work on, then it will come back and bite you. Hard.

Finally, let me shamelessly plug another one of my answers, on the related "Does the ActiveRecord pattern follow/encourage the SOLID design principles?" question, which to me is a far more relevant question than "is it an anti-pattern".


This is akin to asking "is a power drill an anti-pattern?". ORMs earned a good place in my toolbox, reducing my boilerplate code and I am still able to use custom SQL if necessary. So if it is an anti-pattern, which pattern does it go against?

My answer is no, there are plenty of mature ORMs out there that make your life a lot easier and makes your code more understandable. This in any way means you don't need to understand SQL, quite the contrary.

  • 12
    +1 I too think it is very useful, there is a learning a curve. But it is very nice not having to manually populate pojos, etc. Commented Nov 17, 2011 at 16:57

I would hestitate to call something an "anti-pattern" which was first called a pattern by Martin Fowler and has since been embraced in nearly every modern programming language. (See the Wikipedia article on ActiveRecord.)

A good ORM can lead to much less code (and much less repetition) in a project, and nothing is as strongly correlated with bugs as quantity of original code.

ORMs are generally designed to handle the most common use cases for working with databases. Complex queries may still need to be written explicitly. But I would strongly discommend writing explicit queries for every database interaction. In most cases, that's a waste of time.

  • 14
    "I would hesitate to go against argument by authority"
    – Raynos
    Commented Nov 17, 2011 at 16:56
  • 3
    @Raynos: You mean... are you saying... Fowler might have been.... WRONG?!?! shock & gasp Heresy! Blasphemy!! :P ;) Commented Nov 17, 2011 at 16:58
  • 9
    @Raynos - Perhaps authority isn't the best argument, but the OP said "in my experience". This is essentially an appeal to personal authority, so I think it's reasonable to counter with an appeal to authority and consensus. Besides, the term "anti-pattern" is itself about opinions. I've given examples of what other people think. Commented Nov 17, 2011 at 17:01
  • 3
    @NathanLong I was just pointing out that popularity and correct-ness are orthogonal.
    – Raynos
    Commented Nov 17, 2011 at 17:07
  • 1
    FWIW Data Mapper is probably the pattern that most closely maps to an ORM. ActiveRecord is a different pattern, though certainly related.
    – JasonTrue
    Commented Nov 17, 2011 at 17:43

Using an ORM instead of learning SQL is a pretty bad idea. If you don't know exactly the kind of SQL being generated, if you don't understand the N+1 problems and how to optimize then it will definitely cause more harm than good. I feel though, that I am much more productive using an ORM. I prefer Rails ActiveRecord, which does not try to pretend that there is no database and doesn't get in your way if you just need to write SQL. I do worry though that some people may trust the idioms they see too deeply, without a deep understanding of what they are doing.


My experience: I'm using NHibernate with Linq2NHibernate.


  • It gets rid of "Magic Strings", or at least offers a once-and-only-once place to put them
  • It allows me to work in an OO paradigm the entire time
  • The code is easier to read
  • The code built on top is easier to change
  • It allows you to swap out your actual relational database without maintaning 2 separate repositories (rarely done, but that's one big benefit if you need it).


  • The code is harder to write, because
  • It is not a sufficient abstraction -- you still have to be intimately familiar with what it's doing in the background

I will say that it doesn't live up to the promise that most people initially hope for. I wouldn't blame someone for saying that it's an anti-pattern. I find, in my case, that I still need to do integration tests against a SQLite database to make sure that my Linq2NHibernate queries actually work. So really, if you're doing integration tests against a real relational database anyway, then that kind of eliminates the problem with "magic strings".

If I were to start a new project, I'm not sure if I'd use an ORM or not. I probably would, but I can't say for sure you should. I would say it's like the difference between choosing C++ or Java/.NET for your project: are you going to need the flexibility you get with working at a lower level, or would you rather work at a higher level and (supposedly) be more productive? The normal answer is to work at as high of a level as you can get away with. That usually means using an ORM.


The strength of an ORM is that it allows you to model application behavior using object-oriented techniques. In a carefully engineered world, you have one layer of the application where the language of the business neatly meets the language of the development team. The ORM is an enabler of that, if the ORM is used sensibly.

The weakness is that the number of people who actually really, really get object-oriented programming is pretty small. A lot of people write spaghetti and meatballs, with highly coupled objects that have little behavior of their own and the actually behavior ends up in hideous 8000-line "Service" and "Manager" classes, and that code is often so convoluted that everyone's afraid of changing it because they can't figure out what the side effects will be.

Additionally, a lot of people don't really get the relational model. An ORM will not help them get it, and it won't help them by abstracting out the relational model. It just allows you to focus on your domain layer early on and get that right before you start getting too concerned about the database design. If applied well, with the help of sensible schema migration tools, and ORM can help you prevent code debt from building up.

I've built applications in which an ORM kept application code simple, readable, and testable, and had reasonable performance. I've also maintained applications where the pattern was misused and the code was convoluted, untestable, slow, and fragile; it turns out the ORM itself had little to do with this, except that instead of writing bad code that poorly modeled the application domain, the legacy engineering team wrote bad code that poorly modeled the application domain AND bad service-layer code that neglected all of the value that their ORM could provide them.

ORMs won't make you smarter, but in the hands of the right developer, can lead to more maintainable and higher-quality code.

  • I think this confuses using an ORM as a pattern for DB access and an ORM as a fancy code-generator to make DB access easier and better.
    – gbjbaanb
    Commented Feb 27, 2015 at 16:20
  • I am not sure what you mean by that. Your comment doesn't make much sense to me.
    – JasonTrue
    Commented Feb 27, 2015 at 17:13
  • In that an ORM makes a great way to access a DB with a ton of hard work done for you, but if you use it as a design pattern to pretend a DB is a collection of objects, it starts to fall over. Which is what I thought you were saying.
    – gbjbaanb
    Commented Feb 27, 2015 at 18:10
  • I don't think I've ever advocating using an ORM to pretend that you've got a magical object store that doesn't require you to understand how the database work. I said precisely the opposite: If you understand object-oriented programming well AND how databases work, an ORM can help you produce more maintainable code.
    – JasonTrue
    Commented Feb 27, 2015 at 18:46

ORM is a tool. Like all tools, when used appropriately, they work quite well. When used inappropriately, it needs a bigger hammer and some duct tape.

In the case of the current project I'm working on, it will be maintained by non-developers (mechanical engineers, to be precise) and so it needs to be simple and easy to figure out. It will be several years before this group has a budget to hire developers (presuming the next President doesn't abolish the agency involved), so the future maintenance capabilities is a major factor in our considerations.

  • This answer is an answer. Like all answers, when written appropriately, can be quite useful. When written in a non useful manner, it is not.
    – Uri
    Commented Jan 14, 2020 at 16:11

Perhaps the answer lies in the converse of your question: Is storing your application data in something other than a relational database a good idea? What problems are you eliminating, and what other problems will you pick up? Can you live without the ability to easily cross-reference your data (joins) or quickly filter out the records you want based on multiple criteria? Do you not need solid transaction support (assuming your alternative doesn't have it)? Not all applications need an always-consistent-and-complete data store.

I think the real anti-pattern here may be using a relational DB when you don't need one. If you need one, then you need ORM, and it's definitely not an anti-pattern.

  • 1
    WHile I agree that using a relational database if you don't need one is a bad idea, to day that if you use one you need an ORM is ludicrous!
    – HLGEM
    Commented Nov 17, 2011 at 20:03
  • 1
    Um, then how are you going to get your data in and out of the database? Somewhere, something's going to have to map your objects to the relational structure, and re-create them when they're read from the database. Even if you hand-write queries and copy the data into and out of result sets, you're doing ORM.
    – TMN
    Commented Nov 17, 2011 at 20:25
  • 2
    Using stored procs (the only acceptable way to insert any kind of financial data for internal control reasons) to do all database manipulation is not ORM in my mind. I have never seen any value to an ORM for someone who actual knows SQL well. Nor have I ever worked on a system (and I work with very complex Enterprise applications) that was highly dependant on an ORM, they simply aren't good enough when what you do is complex.
    – HLGEM
    Commented Nov 17, 2011 at 21:26
  • 6
    @HLGEM: And what about the data that you get out of the database? When you query the relational database, do you not map the results to objects? In my experience, there are two types of projects that use relational databases: those that use third-party ORMs, and those that include their own poorly-built ORMs. Commented Nov 17, 2011 at 22:34
  • 2
    +1 Carson. You use some kind of ORM no matter what unless you simply return raw DataSets and plaster those over your code (the most egregious offense of all IMHO) since you will always have to map the results of that stored procedure to classes, which is exactly what ORMs do for you. Commented Nov 18, 2011 at 16:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.