ORM Is NOT Inherently Evil

11 commentsWritten on November 25th, 2008 by
Categories: Opinions, Rants

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?

« Populating Entities With Associations From Stored Procedures With NHibernateFirst Look At NHibernate Profiler »

This entry was posted on Tuesday, November 25th, 2008 at 00:06 and is filed under Opinions, Rants. You can subscribe to any comments to this entry via RSS 2.0. You can leave a response, or trackback from your own site.

  • SG

    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.

  • den Ben

    @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 ;-)

  • Pingback: Reflective Perspective - Chris Alcock » The Morning Brew #230

  • Gustavo

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

  • Craig

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

  • http://davybrion.com Davy Brion

    “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

  • SG

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

  • Rob

    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.

  • Brian

    I am a big fan of ORM ideology but am losing faith in them in practice. I wouldn’t contend either way that ORM tools’ performance in an application match the performance of ADO.Net or stored procedures, but I think ORM’s have a long way to go with start-up costs as in the value of time and sometimes money.

    ORM idealists have been stating for a long time that ORM’s are portable and easy to use. I have read place after place that NHibernate is just as good if not better than LINQ and I have heard the same arguments for the opposite. I have followed down the ORM path only to be disappointed by these promises. You might use the argument like you did in your article that my knowledge in the tool isn’t good enough or that I’m not using it right. However, as I’ll described below, I don’t think there’s enough time to gain the expertise needed with some of these ORM’s when there are actual deadlines.

    The current project that I am currently working on has taken far too many months to implement because I’m trying to use ORMs. Prior to this project I learned LINQ which was very easy to learn and quite enjoyable; however, now I need to connect to an ISeries DB2 server. LINQ does not have support for DB2 which breaks one of the promises with portability. Microsoft developed the Entity Modeling framework to achieve this but after much research, I find that it will only work when the database vendor creates connectivity for Microsoft’s Entity Modeling framework. After further research I find that IBM has developed such connectivity but it costs $11,000. There’s very little information about IBM’s framework, no demos that I can find, so I don’t know if it would be worth the money.

    I then find NHibernate and become hopeful. It is touted as a competitor to LINQ, it fully impliments ORM, yadda, yadda. However, as you admitted in one of your posts, the documentation is simplistic and lackluster which for me has been one of the most frustrating things about the product. When beginning with NHibernate a person has a lot of decisions to make. Do you want source code or not. If you do you have to then download SVN and Nant. If you don’t proceed. Then, you have to decide whether you want to map using XML, NHibernate.Mapping.Attributes, or fluent. This involves more research and hopefully you’ve made the right decision.

    Now, you have to decide on a proxy. There appears to be five available. Again, more research and again, hopefully the right one is chosen. So I went down the path of no source code (I now regret that but have since downloaded), Using NHibernate.Mapping.Attributes (I now regret), and using Castle (No regrets, lucky decision). I also attempted to utilize Rhino commons by downloading the source but that in itself left much frustration as I couldn’t get it to compile with Nant and when I submitted questions to the user groups I received no answers. Finding lack of support about NHibernate tools and NHibernate itself is common.

    In my scenario, I’m working with tables that have composite keys (not my choice). I could get the composite key mappings to work but not the associations. Finding clear and useful examples of one-to-many relationships using composite keys is next to impossible. I have now decided to give up on NHibernate because I foresee myself facing even more problems and am going back to a more simplistic and possible approach: ADO.Net.

    In the end, business managers don’t care about ORMs or a person’s troubles with them, they just want the finished product.

    • http://davybrion.com Davy Brion

      @Brian

      Any technology choice should be properly investigated (at least a representative spike should be done) before actually using it in a real project. If you had done the research in advance, you probably wouldn’t have gone with Linq To Sql since it’s very clear that it is limited to SQL Server only. Entity Framework is supposed to be database independent, but it’s always been very clear that providers for other databases aren’t necessarily available and nobody ever said they would be free.

      As for NHibernate, there are indeed many choices, most of which should be made based on the outcome of your spike or your research.

      I don’t think the current problem you’re facing can be blamed on any ORM… i think it’s because your team did not do the proper research in advance. If your team was not given the proper time to do this research, then it’s a management problem that no piece of technology will ever be able to fix.

  • Jon

    I just don’t see the benefits of ORM even from a software development perspective. It really kills the whole point of using a relational database in the first place. There are many reasons (more important than efficiency) why I don’t like ORM and I’ve made a quite lengthy post about it on my blog: 
    http://jonpress.wordpress.com/2012/01/19/mvc-and-object-relational-mapping/

Meta

Recent Posts

Categories

Archives