As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

Yes. Unless you have a generic CRUD application that doesn't do anything of value with the database in which case you shouldn't be using a relational database.
–
RaynosNov 17 '11 at 16:25

@FrustratedWithFormsDesigner: Great post! But that's very similar to my own opinion. So what about the contrary arguments?
–
derphilNov 17 '11 at 16:32

@derphil: You may want to make it less broad, else this will be closed. If you believe it IS an anti-pattern, maybe state why and then ask in what situations is this anti-pattern appropriate (but that might still be too broad).
–
FrustratedWithFormsDesignerNov 17 '11 at 16:50

2

@derphil, there are plenty of counterarguments in the comments to that blog post, have you read them?
–
Péter TörökNov 17 '11 at 17:04

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.

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.

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.

@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.
–
Nathan LongNov 17 '11 at 17:01

2

@NathanLong I was just pointing out that popularity and correct-ness are orthogonal.
–
RaynosNov 17 '11 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.
–
JasonTrueNov 17 '11 at 17:43

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).

Cons:

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.

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.

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.

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!
–
HLGEMNov 17 '11 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.
–
TMNNov 17 '11 at 20:25

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.
–
HLGEMNov 17 '11 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.
–
Carson63000Nov 17 '11 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.
–
Wayne MNov 18 '11 at 16:45

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.

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.
–
gbjbaanbFeb 27 at 16:20

I am not sure what you mean by that. Your comment doesn't make much sense to me.
–
JasonTrueFeb 27 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.
–
gbjbaanbFeb 27 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.
–
JasonTrueFeb 27 at 18:46