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?
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