Why use ORM?

The path to coding Nirvana is a long one. As you navigate these treacherous ways, you’ll find many corpses – of people who have died of SQL over-injection or of Object-Relational-Miscarriage. For those of you who’ve been doing object-relational stuff long enough and have scars in unmentionable places, go back to your drinks. For the rest of you, for whom ‘Why ORM?’ is an interview question, gather around and warm your toes by the electric light.

Seriously, why ORM?

Well, an Object-Relational-Mapping tool basically takes away the pain (perceived) of writing SQL. As object-oriented programmers, we tend to think in terms of objects.

  • An ORM tool keeps your object model separate from your persistence model, i.e., your java code need not know about your database tables. You write your data modification code in a programming language of your choice and the ORM tool will map that to the database for you.
  • In most cases, you don’t have to write much SQL and you really don’t end up writing SQL that caters to a specific database vendor (in the highly unlikely case that you decide to switch databases after writing an application).
  • ORMs also take away the repetitive, mind-numbing job of writing code that maps object properties to columns and vice-versa.

“Goooo ORM!!!”, you say?

Wait. If the only reason you really like ORMs is that they help you avoid SQL, you will eventually be stuck up the proverbial creek without a paddle.

  • While they do reduce development time, there is a bit of a learning curve.
  • For most non-trivial projects, where you have to do more than simple CRUD, ORMs don’t perform quite as well as simple SQL.
  • Badly written application code (the most common kind!) also means that changes to the database will not be transparent to your object model and your application will have a severe case of the shits. -Caching, concurrency support etc. are not really features of an ORM and can be dropped into any application.

In short, if you have a simple project with a none-too-complex object model, use simple JDBC. If you have a complex domain model with ‘interesting’ relationships between the objects, use an ORM.

At some point, however, you will need to tune your application to cater to higher loads and replace some of that auto-generated SQL with something more efficient – which means that if you’re writing an application that uses a relational database you’d better !$@!%@#$% know SQL.