Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of http://computoser.com and http://welshare.com . Worked on Ericsson projects, Bulgarian e-government projects and large scale recruitment platforms. Member of the jury of the International Olympiad in Linguistics and the Program committee of the North American Computational Linguistics Olympiad. Bozhidar is a DZone MVB and is not an employee of DZone and has posted 91 posts at DZone. You can read more from them at their website. View Full User Profile

ORM Haters Don't Get It

05.20.2012
| 10291 views |
  • submit to reddit

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.

Published at DZone with permission of Bozhidar Bozhanov, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Lukas Eder replied on Mon, 2012/05/21 - 2:57am

Why does the ORM topic always lead to rants and counter-rants like this? People, just use the tool that suits your needs. JPA is the right tool for 70% of all problems (or replace the number by the one YOU perceive) - which makes it the wrong tool for the remaining 30% of all problems. There is no final answer to the "ORM debate", which is more of an "ORM non-debate" with everyone ranting all the time.

While you mostly talk about JPA you also mention this sentence here:

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

I sincerely doubt that these things are related. I wouldn't want to build Facebook based on JPA, they have even optimised the PHP language itself to achieve this sort of performance.

Pawel Dolega replied on Mon, 2012/05/21 - 10:50am in response to: Lukas Eder

I don't really agree with some of the statements (especially not with one cited above - 2nd level cache can be of as much help as it is pain in the ass from time to time). Nonetheless I think that in the basis of haters' opinion is kind of a dissapointment with what ORM actually delivers. It meant to ease everything a lot (that is how it was marketed at the begining) but actually it in the same time makes lots of things more difficult (and especially you also obtain new problems in the package which did not exist with plain SQL).

 Don't get me wrong though - I do belive that Hibernate (or JPA) does bring value. It's just not as much as may have been expected. Still pros beat the cons IMHO.

Mark Unknown replied on Mon, 2012/05/21 - 11:37am

I don't really see this as a rant. It is a pretty good step through of the logic of "why if you are using RDMBS and 'Domain Objects' and not using and ORM, that you will be writing your own."

Geoff Longo replied on Mon, 2012/05/21 - 7:42pm

Entities with lazy loading in an ORM like Hibernate are NOT simple Value Objects.  They contain non-serializable framework classes, which to me, makes them anything but "simple".

Secondly, they do not generate better queries than most developers would write.  In fact, outside of the basic cases, it is VERY easy to unknowingly cause the ORM to generate excess and/or inefficient queries (as well as inserts/updates).  So, yes, it is very possible to properly configure the ORM tool to generate efficient sql, however, it is also VERY easy to cause it to run inefficiently.

Thirdly, ORMs, Hibernate in particular, can force the presentation tier to be "session aware" which requires the OpenSessionInView anti-pattern to resolve.

 

Dapeng Liu replied on Mon, 2012/05/21 - 9:38pm

here is another entertaining article http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

I am fine with JPA most of the time, but when the project is getting serious, I will drop JPA completely and plain old jdbc all the way down.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.