Loading ...ORM Is NOT Inherently Evil
Posted by Davy Brion on November 25th, 2008
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?
November 25th, 2008 at 5:24 am
While it’s wrong to assume that ORMs can never work “right”, it’s equally simplistic to assume that anyone who has had trouble with ORM performance wasn’t using them “properly”.
I feel like I have a decent grasp of both databases/SQL and ORMs (or Hibernate, at least), having written tens of thousands of lines of stored procedure code as well as having used Hibernate to develop a 100+ KLOC production system. The ORM design/usage was reviewed and validated by Hibernate consultants working for Red Hat /JBoss.
IMHO, there exist situations which are fairly trivial to handle from a SQL perspective that, in order to get acceptable performance, require using ORM techniques that are often sparsely documented. Reporting often falls into this category, as do operations in which large numbers of objects/records must be matched and/or reconciled. The performance issues typically do not become apparent until a system has hundreds of thousands or millions of rows in key transactional tables.
Of course, systems using straight SQL are not immune to this effect, but there are literally hundreds of books and thousands of articles about tuning SQL queries, while the techniques for obtaining the best results with an ORM are harder to find and, for me at least, involved significant research and trial & error.
In summary, an ORM can definitely be your friend when it comes to reducing the amount of time you need to spend writing data access code, but once you’ve accumulated enough data, you might have to become more than just “friends” with your ORM and become intimate with her inner workings.
November 25th, 2008 at 7:43 am
@SG
Well put!
Luckily it’s the effort that some people invest in ORM technologies (like Davy does with NHibernate) and that they want to share with the developer community (again.. Davy does a nice job at that) which allows us to get acquainted a bit deeper than on just the “friends” level. I plan on making 2nd base in the near future
November 25th, 2008 at 9:39 am
[...] ORM Is NOT Inherently Evil - Davy Brion addresses one of the common developer opinions that Object Relational Mappers are evil [...]
November 25th, 2008 at 1:36 pm
@SG
If you need to optimize the efficiency of an specific query using a well optimized SQL string or SP instead of an HQL or criteria you have a seamless way to do it even without changing the code only the mapping between and so an optimized sql query and ORM keep being compatible, and there isn’t a point there.
I sometimes even don’t know how to write something in HQL, i write it in SQL and when i learn how to do it the HQL way if i benefit from this i replace the mapping if not i live it as is.
Gustavo.
November 25th, 2008 at 1:59 pm
@SG
I agree with your assessment. I also agree with Davy. However, what remains to be said is simply that not every tool fits every situation. You mention reporting. I quite frankly do not even attempt any level of complex reporting using an ORM. There are many reporting tools out there for that. ORM wasn’t meant to solve the reporting problem, so lets not even try to push it into that bucket.
November 25th, 2008 at 2:07 pm
“However, what remains to be said is simply that not every tool fits every situation.”
yes definitely… ORM is great for a lot of applications, but definitely not all of them
and parts like reporting should never work with an ORM IMO
November 25th, 2008 at 4:18 pm
@Gustavo
You’re correct in stating that there are several techniques for addressing the issues I detailed in my post. We utilized the techniques that you suggested as well as several additional techniques. Again, my issue is not a lack of means to address performance issues but that the means often require deeper knowledge of the ORM than is commonly acknowledged.
BTW, HQL was never really an issue with our team, since most people with SQL skills seem to become fluent in HQL within a few days.
@Davy, @Craig
The problem we had with using something other than the ORM to do reporting was that the objects in our model contained logic & behavior that we wanted to leverage on our reports. Not using the ORM meant that we’d be either duplicating behavior or duplicating data access code, neither of which was an ideal solution.
@All
I’d like to echo what Den Ben wrote. The information that is available on the Internet is out there because smart, passionate developers like you care enough to write & comment about the subjects.
To return to my original point, I’ve used and will continue to use ORM solutions, but not every issue that developers have with them is caused by lazy and/or ignorant developers. There are definitely use cases in which developers will need to dig deep into the architecture of the tool in order to extract good performance.
November 25th, 2008 at 9:17 pm
The problem with changing technologies is that people want them to be the very best for every imaginable situation. The holy grail is something people chase for their entire lives but it simply doesn’t exist. Yes, (N)Hibernate is a performant ORM and no it will not work on a ARM4 with 1Mb of RAM nor will it suit your needs in a real time environment. Move on.
Another question might be why we still work with an RDBMS at all and why the hell didn’t OOdatabases kick off? Martin fowler has an interesting view on it in his latest post .
Use what best suits your needs.