Should you use ORM?

Over the last few years, I've seen a heavy trend towards using Object Relational Mapping (ORM) libraries to help manage persistence in Java applications. Is this good or bad? Is ORM the way to go now? To answer that, I think we first need to answer a few questions:

1) What need is ORM addressing?

First and for most, the primary goal is to map data to Java objects. This is done using some sort of definition which tells the library how to query (and write to) the database.

The other big piece is the "relational part" of the equation. Instead of using a foreign key field on a Java object, you would use another java Object to represent a relationship. You would then use an object setter and getter instead of a potentially meaningless key value in your Java code. This actually makes for fairly clear code when writing your business logic.

2) Are there other ways to address this?

Of course there are. As far as the basic data mapping, this a can be readily addressed in a traditional Data Access Object (DAO) with a row mapping method. You could then use plain JDBC if you wish, except the overhead can be quite irritating. Spring does a good job managing this, if you extend their JdbcDaoSupport class. Alternatively, you could use a tool like iBatis to deal with data mapping.

In order to address the relational aspect, one decent pattern I've seen is to introduce a layer of abstraction between your business logic and persistence layer. Essentially, you would create business objects to encapsulate your entity objects, which are just a direct mapping to a database object. You can then represent object relationships at this level.

Obviously, since these approaches require an additional business layer in your application, and manually coded SQL, the ORM approach can make Java coding simpler.

3) What's the downside of ORM?

XML! Well, that's not entirely accurate: In Hibernate, mappings used to be defined only in XML files. To manage your mappings could be quite complex and was error prone. I've seen a lot of time wasted just in the overhead of dealing with Hibernate XML. A full discussion on XML based tools is best saved for another day.

Fortunately, Hibernate eventually decided to give you annotations. Now you can define your mappings simply by throwing a few annotations on you entity class. Even better, Hibernate implements JPA, so you don't actually have to explicitly use Hibernate at all, in most cases. JPA gives you a standard that several ORM libraries can implement. This makes it much simpler to change your ORM, for example, to TopLink if you choose.

A specific problem I have with ORMs, is the query DSLs you need to use in place of SQL. Since you are dealing with objects instead of database tables, there are special languages, such as JPQL (in JPA) or HQL (in Hibernate) which your developers have to learn in order to do any non-standard queries.

In addition to the learning curve, these queries have the added problem that performance can
be unpredictable. Since the query DSL will be translated by the ORM into SQL, it is difficult to know what SQL will actually be executed. Unless your ORM provides you some sort of flexibility in this regard, tuning can become a huge issue. While I don't advocate trying to fix performance bottlenecks before they are identified, there is wisdom in ensuring your design gives you flexibility in this regard.

Finally, there's the gotchas. You need a good understanding of session and transaction management, as well as dealing with caching and lazy-vs-eager loading. These things are manageable, but be warned!

Are there any other benefits?

With the maturity of ORMs, the tooling has also come along way. Tools have become available that help to simplify your ORM implementation, even to the point of auto-generating your objects based on a database schema.

The benefits swing the other way, as well. With some ORM tools, you can define your objects and mappings and actually use these to generate your database schema. This can be a big win.

Final Answer: Should you use ORM?

It depends. Based on what I've seen, there is a place in Java development for object relational mapping. The biggest win is helping to simplify your design. That said, you also assume some risks and add overhead complexity to your application.

On a fairly simple project, ORM may be the most ideal way to go. On larger, more complex projects, you might want to use a different approach with a slightly bigger design. Where appropriate, you may even want a hybrid using ORM for general purpose and a different approach for the more complex pieces. Of course, doing this comes with significant risks of its own.

The bottom line is that you need to ask yourself what is most appropriate for your project based on:

• project complexity
• project needs
  
• the team's skill set
• comfort level
• cost vs benefit