Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as not constructive by gnat, Walter, Matthieu, Mark Trapp, Jim G. Sep 4 '12 at 18:32

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.

3  
Have you read this: seldo.com/weblog/2011/08/11/orm_is_an_antipattern ? –  FrustratedWithFormsDesigner Nov 17 '11 at 16:12
2  
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. –  Raynos Nov 17 '11 at 16:25
    
@FrustratedWithFormsDesigner: Great post! But that's very similar to my own opinion. So what about the contrary arguments? –  derphil Nov 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). –  FrustratedWithFormsDesigner Nov 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ök Nov 17 '11 at 17:04
show 4 more comments

8 Answers

up vote 65 down vote accepted

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

share|improve this answer
16  
+1 Good answer to an unconstructive question –  maple_shaft Nov 17 '11 at 18:10
3  
+1 for working in the phrase "impedance mismatch". Buzzwords for geeks, but I like them too! –  hardmath Nov 17 '11 at 19:58
    
Totally agree...check this link is so good explained:seldo.com/weblog/2011/08/11/orm_is_an_antipattern –  sandino Nov 15 '12 at 3:36
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
10  
"I would hesitate to go against argument by authority" –  Raynos Nov 17 '11 at 16:56
2  
@Raynos: You mean... are you saying... Fowler might have been.... WRONG?!?! shock & gasp Heresy! Blasphemy!! :P ;) –  FrustratedWithFormsDesigner Nov 17 '11 at 16:58
8  
@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 Long Nov 17 '11 at 17:01
2  
@NathanLong I was just pointing out that popularity and correct-ness are orthogonal. –  Raynos Nov 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. –  JasonTrue Nov 17 '11 at 17:43
show 3 more comments

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.

share|improve this answer
8  
+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. –  NimChimpsky Nov 17 '11 at 16:57
add comment

My experience: I'm using NHibernate with Linq2NHibernate.

Pros:

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 Nov 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. –  TMN Nov 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. –  HLGEM Nov 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. –  Carson63000 Nov 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 M Nov 18 '11 at 16:45
show 1 more comment

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