Bozhidar Bozhanov

About Bozhidar Bozhanov

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of Computoser and Welshare. Worked on Ericsson projects, Bulgarian e-government projects and large-scale online recruitment platforms.

ORM Haters Don’t Get It

I’ve seen tons of articles and comments (especially comments) that tell us how bad, crappy and wrong is the concept of ORM (object-relational mapping). Here are the usual claims, and my comments to them:
  • “they are slow” – there is some overhead in mapping, but it is nothing serious. Chances are you will have much slower pieces of code.
  • “they generate bad queries which hurts performance” – first, it generates better queries than the regular developer would write, and second – it generates bad queries if you use bad mappings
  • “they deprive you of control” – you are free to execute native queries
  • “you don’t need them, plain SQL and XDBC is fine” – no, but I’ll discuss this in the next paragraph
  • “they force you to have getters and setters which is bad” – your entities are simple value objects, and having setters/getters is fine there. More on this below
  • database upgrade is hard – there are a lot of tools around the ORMs that make schema transition easy. Many ORMs have these tools built-in
But why do you need an ORM in the first place? Assume you decided not to use one. You write your query and get the result back, in the form of a ResultSet (or whatever it looks like in the language you use). There you can access each column by its name. The result is a type unsafe map-like structure. But the rest of your system requires objects – your front-end components take objects, your service methods need objects as parameters, etc. These objects are simple value-objects, and exposing their state via getters is nothing wrong. They don’t have any logic that operates on their state, they are just used to transfer that state. If you are using a statically-typed language, you are most likely using objects rather than type-unsafe structures around your code, not to mention that these structures are database-access interfaces, and you wouldn’t have them in your front-end code. So then a brilliant idea comes to your mind – “I will create a value object and transfer everything from the result set to it. Now I have the data in an object, and I don’t need database-access specific interfaces to pass around in my code”. That’s a great step. But soon you realize that this is a repetitive task – you are creating a new object and manually, field by field, transferring the result from your SQL query to that object. And you devise some clever reflection utility that reads the object fields, assumes you have the same column names in the DB, reads the result set and populates the object. Well, guess what – ORMs have been doing the same thing for years and years now. I bet theirs are better and work in many scenarios that you don’t suspect you’ll need. (And I will just scratch the surface of how odd is the process of maintaining native queries – some put them in one huge text file (ugly), others put them inline (how can the DBAs optimize them now?))
To summarize the previous paragraph – you will create some sort of ORM in your project, but yours will suck more than anything out there, and you won’t admit it’s ORM.
This is a good place to mention an utility called commons-dbutils (Java). It is a simple tool to map database results to objects that covers the basic cases. It is not an ORM, but it does what an ORM does – maps the database to your objects. But there’s something missing in the basic column-to-field mapper, and that’s foreign keys and joins. With an ORM you can get the User’s address in an Address field even though a JOIN would be required to fetch it. That’s both a strength and a major weakness of ORMs. The *ToOne mappings are generally safe. But *ToMany collections can be very tricky, and they are very often misused. This is partly the fault of ORMs as they don’t warn you in any way about the consequences of mapping a collection of, say, all orders belonging to a company. You will never and must never need to access that collection, but you can map it. This is an argument I’ve never heard from ORM haters, because they didn’t get to this point.
So, are ORMs basically dbutils plus the evil and risky collection mapping? No, it gives you many extras, that you need. Dialects – you write your code in a database-agnostic way, and although you are probably not going to change your initially selected database vendor, it is much easier to use any database without every developer learning the culprits if its syntax. I’ve worked with MSSQL and Oracle, and I barely felt the pain in working with them. Another very, very important thing is caching. Would you execute the same query twice? I guess no, but if it happens to be in two separate methods invoked by a third method, it might be hard to catch, or hard to avoid. Here comes the session caching, and it saves you all duplicated queries to get some row (object) from the database. There is one more criticism to ORMs here – the session management is too complicated. I have mainly used JPA, so I can’t tell about others, but it is really tricky to get the session management right. It is all for very good reasons (the aforementioned cache, transaction management, lazy mappings, etc.), but it is still too complicated. You would need at least one person on the team that has a lot of experience with a particular ORM to set it up right.
But there’s also the 2nd level cache, which is significantly more important. This sort of thing is what allows services like facebook and twitter to exist – you stuff your rarely-changing data in (distributed) memory and instead of querying the database every time, you get the object from memory, which is many times faster. Why is this related to ORMs? Because the caching solution can usually be plugged into the ORM and you can store the very same objects that the ORM generated, in memory. This way caching becomes completely transparent to your database-access code, which keeps it simple and yet performant.
So, to summarize – ORMs are doing what you would need to do anyway, but it is almost certain that a framework that’s been around for 10 years is better than your homegrown mapper, and they are providing a lot of necessary and important extras on top of their core functionality. They also have two weak points (they both practically say “you need to know what you are doing”):
  • they are easy to misuse, which can lead to fetching huge, unnecessary results from the database. You can very easily create a crappy mapping which can slow down your application. Of course, it is your responsibility to have a good mapping, but ORMs don’t really give you a hand there
  • their session management is complicated, and although it is for very good reasons, it may require a very experienced person on the team to set things up properly
I’ve never seen these two being used as arguments against ORMs, whereas the wrong ones in the beginning of this article are used a lot, which leads me to believe that people raging against ORMs rarely know what they are talking about.
Reference: ORM Haters Don’t Get It from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog.
Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

10 Responses to "ORM Haters Don’t Get It"

  1. vernetto says:

    what is crappy is not ORM, but some of its implementations, like EclipseLink. I also lament that JPA provided a wrapper around some illustrious high quality implementations, like Hybernate, but removing some very valuable stuff (wrappers are usually worse than the thing they wrap, see also Sping’s Hybernate wrapper…)

  2. Chris says:

    Having used Hibernate and having taken a class in RDB, I found that I can get better performance from executing custom queries on views that I wrote than relying on Hibernate to build efficient queries.  Mind you, those queries were joining 4 or more tables and in one case, the schema had a foreign key to the primary key of the same table (self referential). My conclusion is that if you are building a something simple like a billing system then you really need Hibernate.   If you are doing anything even vaguely computational like natural language processing, then you need to avoid Hibernate.  It has it’s place and it isn’t prototyping or proof of concept.

  3. “it generates better queries than the regular developer would write, and second – it generates bad queries if you use bad mappings” This is why you make sure your dev team isn’t made up of ‘regular developers’. Are ‘regular developers’ that write bad SQL able to make good mappings?

  4. Sassan Aria says:

    I am a big fan of ORM’s when they are used for the right project. The best candidate for ORM is a project for which there is a straight-forward data model with clear relationships that are expressed in terms of FK/PK and a 1-1 mapping between the fields in the beans/DTO and the table columns (in other words, the ORM Happy Path). Unfortunately, in my experience only a few of applications I’ve seen fall into this category (and they are typically simple apps, and relatively static in terms of data model requirements).

    The majority of the large scale applications (especially in finance and healthcare), are comprised of about 80% Happy Path, and 20% *Ugly-But-Necessary* data that needs to be stored. I have worked on many projects where we’ve had true ORM experts (Hibernate and JPA both) just throw up their hands and concede that it’s not possible to achieve the the 20% using the ORM solution (short of some hideous hacks and band-aids). At that point if one sticks with the ORM, one gets into this whole trying to get the “custom” non-ORM code to co-exist with the ORM layer and inevitably it becomes a maintenance nightmare. For these type of projects, 95% of the time (once the maintenance becomes too costly and the scale tips), the decision is made to do away with the shiny ORM for a simple commons-dbutils type of approach with fine grained control over the 20% (which is tedious, but maintainable in the future).

    I’m sure all of this sounds familiar to anyone who’s put enterprise apps into production and seen them evolve.

    So it’s not that the ORM opponents don’t get it, it’s that ORM is mostly a liability in the long-lived, large enterprise apps that don’t adhere to the ORM Happy Path.

    (as an example of the what an ORM just can’t do, consider that most complex financial apps have about 5-10% of data for their objects stored in an EAV format).

    http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

  5. Richard Bucker says:

    ORMs are good for simple CRUD so that you do not have to repeat various coding strategies… but it/they must be capable of supporting hand optimized SQL programming and should not have their own DSQL. (Domain Specific Query Language). That simply does not scale.

  6. Ian says:

    I agree with all the comments so far and especially Sassan Aria’s comment. ORMs are one of those ‘good in theory’ ideas, but in the real world with real complexity and real database ugliness that occurs with any database that has been around a while, ORM’s fail at the last 10%. It’s a very well known problem.

  7. marcello Dias says:

    Hi,
    I´ve never seen a regular developer, just good and bad ones.
    If you´re a bad one ,and don´t know SQL very much I suggest you read all Joe Celkos books.
    Joe Celko as far as i Know is one of the so called ORM haters.
    I´ve never even tried to use an ORM tool , just because nobody ever convinced me I really needed one.
    “You can code for every RDMS”,What about the SQL ANSI Syntax?
    If you change a field Type ,you don´t have to change code everywhwre,In 25 years I had to change the type of field three times, every time in somebody else made databases ,that just made the wrong decisions because he was an idiot.
    I Love OOP,That was a change in history,in fact at first it was really annoying to see what fields should or not be update and so on,but after one year I have developed my all classes that did it we very little code.
    My own orm Mapping tool,with more coding?
    Maybe,But I allways knews what was happening,no one to blame but myself.
    Is there any bank using ORM?
    Any Big ERP using ORM?
    All I allways see is Facebook,Instagram and bla,bla,bla.
    Software must be deterministic ,If I wrote a Query I need this query to be exaclty What I wrote in the next 60 years,If the software dies first,it is not my problem.They were tested.
    I know there are automatized tests, but in no way a computer will ever be as smart as a persons eyes,it can help us,but will never be smarter than us,they can be faster ,not smarter.
    At least in Brazil the quality of programmers have decreased a lot,no one knows at an algorithm is,they don´t know how to design a database and expect that a magic framework will do the miracle,and if it not as fast as it should be,buy more machines,with more memory,more disks and that’s enough.

    • Marcello Dias says:

      Hi ,
      When I said Joe Celko is an ORM Hater,I should have used commas,because Nobody is a hater of a technology,people like,dislike or ignore it,it was just to play with the articles name.
      I myself desagree with Joe CElko in some points,I think he is too data minded in the case of not using surrogate keys.

  8. Marcello Dias says:

    Another thing,I don like to say an article is bad written or it is garbage.
    But saying that human resources cost more than machine time is a ridicolous thinking of someone who made software to himself or to use internally for just one company.
    How can you measure an hour of someone who coded for SAP,ORacle Business,JD Edwards,Microsoft DYnamics.software that runs in millions of machines in millions or at least hundreds of thousand servers?
    IF these guys have created slow software,would you really compare an hour of his work to the million dollars it would cost to buy more machines and pay people to administer them.
    I thinks thats why these huge companies and banks don like to hire the so called “Average developpers”.

Leave a Reply


2 × one =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books
Get tutored by the Geeks! JCG Academy is a fact... Join Now
Hello. Add your message here.