Skip to content

ORM-is-Dead meme

I agree with Stephan, and  Aldo; ORMs increasingly get in the way.

Collection mapping is one of those “hello world” problems. (The “hello world” example in the doco looks totally trivial and completely ideal [which is the problem], but suck-in-the-galaxy-greet-it-and-then-map-all-the-stars problem, which is more like what your real app looks like, is far less than trivial and not so easily achieved with the demonstrated toolkit). In my experience, collection mapping is the cause of all sorts of pain and performance perfidy.

Here’s a further situation where I find that they really get in the way. Consider integration with existing systems that use highly-normalised database schemas (designed by advanced SQL programmers who know what they are doing in that language).

This is not an uncommon scenario – we have this system ‘A’ which (let’s say) has all our customer shipping, product, warehousing data in it. We don’t want to replace it. But we need to extend it so that e.g. available to web systems. Or maybe it needs to be integrated into the big fancy off-the-shelf CRM we’re installing. Something like that. We need to build some sort of service layer around this system ‘A’ so that other systems can access its data and/or functions. It’s common to think that an ORM around that big complex database schema is going to help, but in my experience, it doesn’t for many of the reasons Stephan and Aldo list. That sort of highly-normal database schema in my experiences completely kills ORM object representations stone cold. You end up with so many LazyInitialisationExceptions and various other problems it sucks productivity out the developers and performance out of the system.

Also, I get a bit annoyed about ORM abstractions leaking into the web tier, this is especially prevalent with using annotations rather than ORM mapping files.

Different sorts of approaches are sometimes needed to be applied with careful thought in that scenario. Perhaps you need to model the “intermediate” domain you need directly, and then use, for example, simple DAO layers which operate directly on the domain you’ve defined. These DAO layers then might call functions (stored procs) in the database that do the problematic mapping in an efficent relational language (after all it’s the direct representation of the target data format).

I’m not saying that you have to do the above in every case, or that an ORM is always wrong, but anyway the point is, ORM isn’t a magic bullet like any other technology you have to consider carefully. Your application doesn’t always need one by default.


  1. “Also, I get a bit annoyed about ORM abstractions leaking into the web tier, this is especially prevalent with using annotations rather than ORM mapping files.”

    Hurray, another soul who doesn’t think annotations are the way to go with Hibernate.


    Monday, October 19, 2009 at 18:05 | Permalink
  2. Scot Mcphee wrote:

    Oh … I find Hibernate annotations evil. Generally if I find teams really wanting to use them I then ask that the objects so annotated never go past the DAO layer, i.e. do not form part of the DAO signature. You should see the consternation that causes! The idea that some web command object using a service layer has to import org.hibernate.anything is beyond comprehension — you’ve just exploded the whole point of layering systems right there!

    There’s an additional wrongness about hibernate annotations (and in fact most uses of annotations that I see). Whatever happened to the separation of code from configuration? I don’t find any problem with using the .hbm.xml files. People who say “it makes you look in two files” are wrong – you just need the .hbm.xml file to grok the mapping.

    Monday, October 19, 2009 at 18:24 | Permalink
  3. “[…] you’ve just exploded the whole point of layering systems right there!”


    Monday, October 19, 2009 at 18:30 | Permalink
  4. The need to have annotations in your classpath to load classes was an early Java 5 bug – more recent versions of Java 5, and ALL versions of Java 6, do not need annotations present.

    So, for example, if you’re building a classic EAR with EJB and WAR, or an OSGi-app with good classloader partioning, you can have a DAO that is full of hibernate annotations and not have said annotations on the classpath of the web app/client app/etc.

    Of course, if you’re using Maven to do this, it’s more painful – Maven insists on pushing compile-scope out to end users.

    Monday, October 19, 2009 at 20:07 | Permalink
  5. Scot Mcphee wrote:

    You know my position on this Robert ;-) … why would you ties your interface domain model to your database design? If it’s that simple, you barely need an ORM anyway!

    Monday, October 19, 2009 at 21:32 | Permalink
  6. *shrug* If it’s transparent to the next tier, that means they won’t know if you put it in, or if you take it out. So why complicate things before it’s necessary?

    Hibernate can do that, if you put in a repository pattern to handle loads & searches, etc. I agree totally that your web app shouldn’t need to import org.hibernate (or iBatis, or anything) – that’s just silly.

    My domain model trumps the database design – if it’s easy to map, I do it directly, if it’s not easy to map, well that’s where things like components & custom types come in.

    But my strong preference isn’t to have a database at all. :) ORM isn’t dead, but it is dead boring…

    Monday, October 19, 2009 at 22:02 | Permalink
  7. Dan Howard wrote:

    Why do people keep torturing themselves with Hibernate anyway?

    Wood simple and is never in your way.

    Tuesday, October 20, 2009 at 23:56 | Permalink

3 Trackbacks/Pingbacks

  1. […] This post was mentioned on Twitter by Stephan Schmidt and scot mcphee, Willy Mejía. Willy Mejía said: RT @codemonkeyism: RT @scotartt: ORM-is-Dead meme […]

  2. uberVU - social comments on Tuesday, October 20, 2009 at 11:49

    Social comments and analytics for this post…

    This post was mentioned on Twitter by scotartt: ORM-is-Dead meme

  3. Blog harvest, October II « Schneide Blog on Monday, October 26, 2009 at 05:21

    […] how to use it – and when not to. Replies followed instantly, here are two noteworthy ones by Scot Mcphee and by Jens […]