the blog for developers

ORMs are a thing of the past

ORMs are a thing of the past. Hold your anger! I always thought ORMs were the next best thing after sliced bread. I was so convinced about ORMs that I wrote some of them on my own in Ruby and Java – not very good, mind you – during the 90s. Later I switched to commercial ones and settled with Hibernate and JPA for many projects. But after years of usage and seeing developers on my teams work with Hibernate, I’m no longer sure it is a good thing.

Beware: This is a non-conformist post. I’m also one of the very few people who think JPA/Hibernate annotations are bad for your domain classes. Keep this in mind while reading further.

Problems with ORMs

They are a delusion. They help you getting up to speed fast and prevent you from writing noisy boiler code. Over time they will pose problems, those problems becoming bigger than the speed you’ve gained. The biggest two:

  1. ORMs are most problematic due to performance concerns. Many developers I’ve met never look into Hibernate SQL logs to see what queries are generated, and how many of them. Should they ever look in the SQL which is executed, their eyes will pop up. Mine did. Nearly.
    As Aldo wrote in “A Farewell to ORMs”

    Whether or not the magical plumbing is worthwhile depends largely on how often the abstraction breaks down. The ORM approach does so frequently. Yes, I can use an ORM and think at the object level in the common case, but whenever I need to do anything remotely complicated – optimising a query, say – I’m back in the land of tables and foreign keys. In the end, the structure of data is something fundamental that can’t be simplified or abstracted away. The ORM doesn’t resolve the impedance mismatch, it just postpones it.

  2. Leaky abstractions. You think the ORM works but it doesn’t. It throws exceptions to you. Lazy initialization exceptions in Hibernate popping up in the most unfortunate circumstances because you made wrong assumptions about sessions, scope and flow. These are hard to find and often harder to fix.

But these are not the main reasons for the phasing out of ORMs over the next years. Additionally ORMs may hinder future development and not be a safe investment because they lose their grip on enterprise development with the advent of NoSQL data stores. Polyglot persistence will make it harder to store data via ORMs, as thouse would need to cross reference stores. This is all highly speculative, and could be countered by: “Well, SQL isn’t safe either”. But nevertheless it needs consideration.

Solutions without ORMs

The most common argument against the performance impact of ORMs is to use caching. Caching in Hibernate does reduce the number of queries indeed. But caching done in XML, JSON or HTML is often more efficient than object caching. And should you need object caching, other solutions beside ORMs exist which explicit caching of objects like ehCache or Terracott in Java.

What about less boiler plate code due to ORMs? Good DAOs with standard CRUD implementations help there. Just use Spring JDBC for databases. Or use Scala with closures instead of templates. A generic base dao will provide create, read, update and delete operations. With much less magic than the ORM does. And although others think that DAOs are dead, the fraction of persistence increases the need for DAO abstraction. The downside of managing relations yourself isn’t as large as ten years ago, with many web databases denormalized. Or with part of the data already in NoSQL document databases.

Think about ORMs the next time you start a project.

About the author

stephan Stephan Schmidt has been working with internet technologies for the last 20 years. He was head of development, consultant and CTO and is a speaker, author and blog writer. He specializes in organizing and optimizing software development helping companies by increasing productivity with lean software development and agile methodologies. Want to know more? All views are only his own. You can find him on Google +

Discuss on Hacker News Vote on HN