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?
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.
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.
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.
Pros:
Cons:
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.
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.
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.
