ORM Is NOT Inherently Evil
There were some comments on a previous post about how the problem described in that post is somehow typical for applications that use ORMs. I really could not disagree more.
It seems that even today, in 2008 mind you, we still have a lot of people who are convinced that ORM usage can never be as efficient as the more classic data access approaches. Now, i don’t even want to get into the whole debate about where business logic belongs (but if you think it belongs in the database you no doubt have better things to do than reading this blog), but one thing that does bother me tremendously is that a lot of people discard ORMs because they simply don’t know how to use it properly.
An ORM is a tool. Nothing more, nothing less. Well, it is a pretty powerful tool and, as with any other powerful tool, improper usage of said tool can really cause a lot of problems. Should we discard the tool because a lot of people never took the time to figure out how to use it properly? That would be kinda stupid, no?
It seems to me that a lot of people seem to have this misconception that using an ORM essentially leads to data-fetching in tremendously inefficient manners. They see the tutorials where only the ‘get-by-id’ functionality and the lazy loading features are shown and they somehow think that’s all there is to it. They hear all the horror stories about projects that performed terribly because the developers used an ORM and they blame the tool, not the developers. Nevermind the fact that there are plenty of projects that use more classic data access approaches who perform like shit as well.
So let’s try to get a few of these misconceptions out of the way, shall we?
- You can create highly efficient queries with an ORM tool, and you can actually do so in a manner which enables high developer productivity
- ORM’s are not slow by definition. Using them wrong (just like with any other data access technology) can be tremendously slow however. Who’s at fault?
- ORM’s do not use a shitload of memory. Improper usage of them however can lead to excessive memory usage. Blame the developer, not the tool.
- ORM’s do not lead to lazy developers, who are doing lazy coding by relying on lazy loading. Bad developers lead to lazy coding by relying on lazy loading.
So, for those who think that ORM’s can never work ‘right’, i have only one question: are you absolutely sure you know what you’re talking about?
ORM isn’t evil, but it ain’t Philly cream cheese either. It is the flavour of the month/year for both admiration and criticism. A great or powerful tool doesn’t make for a great product if the user of that tool doesn’t have the time or commitment to learn how to use it. Try explaining to a manager that there’s a technology out there that no one in the team really understands yet, but promises to save us time & money, *but* we need to spend several weeks studying up and experimenting with it before we’re sure we can put it into our project… They tend to get excited about the first bit, and devs end up eager to “dive in” without checking the water first.
Unfortunately, the projects I have entered that were already committed to using NHibernate adopted it without fully understanding how to use it properly. Any time saved by using it has been spent twice over resolving issues either related to it, or working around limitations in its implementation. I try not to let it bias me too much. 🙂
ORM isn’t evil, but it ain’t Philly cream cheese either. It is the flavour of the month/year for both admiration and criticism. A great or powerful tool doesn’t make for a great product if the user of that tool doesn’t have the time or commitment to learn how to use it. Try explaining to a manager that there’s a technology out there that no one in the team really understands yet, but promises to save us time & money, *but* we need to spend several weeks studying up and experimenting with it before we’re sure we can put it into our project… They tend to get excited about the first bit, and devs end up eager to “dive in” without checking the water first.
Unfortunately, the projects I have entered that were already committed to using NHibernate adopted it without fully understanding how to use it properly. Any time saved by using it has been spent twice over resolving issues either related to it, or working around limitations in its implementation. I try not to let it bias me too much. 🙂
@Steve Getting proficient in any technology always involves a learning investment. This is not something that is only the case with ORM frameworks. Learning an ORM like NHibernate is learning about good data access practices. What you also get at the end is developer productivity, which is also nice to have.
You shouldn’t shoot a particular technology for failing the project because developers never took the time to learn, instead shoot the developers for not learning.
Like Jeremy D. Miller said on his blog once: writing ADO.NET or SQL by hand is stealing money from your employer.
That is exactly why we need ORMs.
well, jpa is not evil
linq is another thing 🙂
Well spoken!
Personally i like the approach to first model the domain (or the ‘world of the objects’ if you want) and think of persistence as an afterthough (and not be data driven). Under this view, persistance is only a concern or a kind of aspect.
Using an ORM (if you know how to smoothly integrate with the object desgin) isn’t any more difficult than any other approach. I think you said it right: a fool with a tool is still a tool – you always have to know about the ‘inner mechanics’ of your ‘weapons’ – otherwise it will backfire …
Greetings
Mario
I prefer my tools to be as close to what I need as possible. If I need to chop down a tree, give me an axe or at most a chainsaw. There might be some nifty Chainsaw on an rope out there that if you’re Jet Li you could swing around your waist, under a leg and cut down 4x as many trees, but I only want to cut down one, preferrably without the reasonable risk of lopping off my own head. 🙂
Most of the problems I’ve seen with NHibernate is when it’s implementation is too embedded in the application. I’m coming into projects with 1-1 table to domain object mapping, and unit tests that are essentially mapped to a “test” database. NHibernate isn’t to blame for bad design, but it certainly doesn’t make debugging & fixing issues any easier. In the real world, re-write is rarely if ever an option.
As a developer who has been cautious of ORM, eagerly trying to learn it, yet not using it full time, I would like to know how it can be used better.
I was hoping that this article might explain some of the “why”, rather than just simply stating “its not bad” (that bit I can guess).
The problem I have is that I work in a fairly procedural environment (using objects for common functionality between projects), but have yet to get any further, simply because every time I see an ORM implementation, I also see the number and quality of the SQL statements, and wonder how the system can possibly be considered efficient.
To put this into context, I’ve worked on a few major clients (not naming names, but have a look at some of the major car manufacturers)… and with these procedurally built websites, they are all capable of running on a single server (typically a shared server with other clients) without any performance issues… while I know of a few other sites that use ORM, where the system requires at least 3 high performance servers (1 database, 1 master web and 1 slave web), and with the same kind of traffic, are still having problems with the load.
as for how it can be used better, that would be a lot to cover in one post…
you might wanna take a look at some of the posts i have in my nhibernate category:
http://davybrion.com/blog/category/nhibernate/
and again, as far as the performance thing goes, it really depends on the developers. good developers write fast code with ‘classic’ data access approaches. they also write fast code with ORM’s, although i expect productivity to be higher.
bad developers write slow code with ORM’s, or any other data access approach you give them
i really don’t think that the whole procedurally built vs ‘true OO’ thing has anything to do with it… you can make both approaches extremely slow, or very fast.
NHibernate is an ORM.
My experience with NHibernate was bad.
Therefore, all ORMs are bad.
Invalid syllogism.
You claim that ORM does not have these problems but fail to give examples. I’ve researched ORM for previous projects (as a DBA nd developer) and the problem is that it is duplicitous in its work (as shown in your example from the opposing webpage), bloated and (as a result) slow.
Want to prove that guy wrong? Show an example where he SHOULD hav done it better in ORM. I personally would love to see it. I know how to do it with a set of methods mapped to an SQL layer so that I get the best response times on my queries for my app so I’d love to see an equivalnet response that you think is equally fast.
the example in the other post is _not_ an example of ORM usage. Some people use an ORM that way, but that’s an entirely wrong way to use it. If you want examples on how to properly use an ORM, there are more than plenty to be found and if you haven’t found them yet, i honestly think you haven’t really looked all that hard.
Well lets put it this way, I am the a maintainer of an MVC framework and we were considering building in ORM support. Our benchmarks without ORM were such that we were the fastest MVC framework out there. Testing with ORM costs us major bandwidth.
I wasn’t involved in all the test as I’m more of a DBA but I did do the benchmarks and they were horrible each time. ORM didn’t even come close. So we left it as optional.
The separate sql layer works perfectly and allows for separation and associating a dataobject with each method in the model and it doesn’t cost us an ounce of speed or scalability.
My issue appears to be the issue that alot of people have who have to scale medium to large systems and ORM causes you to lose alot of bandwidth when you can just as easily establish as sql layer to create that separation you desire without loss of speed or performance.
if an ORM is using more bandwith than a typical SQL layer, you are seriously using it incorrectly… which is kinda the point i was trying to make with this post. it appears i have failed 😉
Proper ORM usage should never lead to more data going over the wire than you really need. You can just as easily instruct the ORM to send proper queries and not hit the database more frequently than you would with a tailor made SQL layer
Then provide an example because all the examples and data I have read are similar to that guys example where the mapping is very static and you are expected to recycle objects rather than building the query to fit the job.
I mean as a classic example, if I just need to grab a login from the user table and no additional data, I have to pull the entire user object thus pulling ALL user data mapped to that user. This is bloated. Doing this for one query is nothing but for 1000 or 10000 adds up.
Doing joins are impossible unless you explicitly declare them and then what is the difference between that and an sql layer? None. To optimize, you again have to go back to hand coding sql which is the whole point to getting your database to be fast and scalable.
To which the sql layer is the best answer again.
for starters, you could take a look at this:
http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/querycriteria.html
http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/performance.html#performance-fetching
http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/performance.html#performance-multi-query
http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/performance.html#performance-batch-updates
there is a lot more information available on how to properly formulate queries and how to properly use an ORM. You just have to be willing to properly investigate a technology before you dismiss it.
seriously, take a look at the documentation… there are plenty of ways of fetching only the data that you need.
You can also use joins when you _need_ to, or you can avoid them when you _don’t need_ them
Please don’t make statements that are incorrect, it really doesn’t help your arguments at all
Tested with hibernate. Thats what we were using.
Thats why I stated the above.
sorry to tell you this, but then you really didn’t read the documentation on what kind of options were available
Could you at least go over the links i posted instead of simply stating “it used more bandwith?”
you already mentioned that you weren’t involved with all the tests, so you can’t possibly claim that it is by definition slower if you’re not even sure how the tests were implemented. Furthermore, your other statements regarding what is or isn’t possible with an ORM are incorrect as well. How much longer would you like to keep this up? You could probably invest this time more wisely in other matters… such as making sure you know what you’re talking about.
Seriously, it’s an MVC framework. We don’t take these moves slightly. It’s a complete rethinking of the framework and ORM maes it EASY for people to handle databases. That’s a big plus.
However, there is always an engineering tradeoff; you cant make something easier to use without adding bloat. Ruby found that out when people kept saying that it doesn’t scale and CTO’s started dumping it. ORM is also problematic in the same way.
Does this mean it is not useful? No. For small and medium projects that do not expect large amounts of growth and don’t have a DBA or other development resources, this may be ideal. But for those who do have a DBA who can tweak the queries for speed and scalability and if you do plan your website for growth, you should be ditching ORM and be building an SQL layer as you will be hand coding everything anyway.
Friends of mine who work for AT&T who went with ORM for one of their apps ended up hand coding ALL their queries and I asked ‘so what is the point of ORM then’ and they said ‘basically none’. They could have done this with a sql layer just as easily and actually saved ALOT of time.
I understand your skepticism, after all you are a true believer and probably haven’t had to scale a 10 terabyte database yet for over 1 million daily customers. I don’t expect you to believe I have read and tried this with my team after all you believe whole heartedly that this stuff works.
But having tested this and benchmarked it with hibernate, I can tell you it is indeed slower.
You can blame it on developers all you want. You can sit here and say everyone else is wrong. You can tell me as the maintainer of an MVC framework that I am wrong as well. But it won’t stop people from saying it. And at some point, you may just do your own benchmarks against a sql layer… and you may find the same exact thing.
I guess trying to talk anymore on this would be like Jesus trying to convince the Pope that he’s an athiest.
regardless of the whole ORM vs SQL layer debate which we obviously can’t agree on, could you please point out what exactly an MVC architecture has to do with an ORM? They are in no way related, other than the fact that many people use them together… there is nothing in MVC which implies usage of an ORM.
Btw, the reason i’m asking is because you seem to be throwing your MVC credentials around to prove your point, whereas i’m just wondering what on earth that has to with the ORM discussion 🙂