Hibernate, iBatis, Java EE or other Java ORM tool

Question

We\'re in the process of planning a large, enterprise application. We\'re focusing our efforts on evaluating hibernate after experiencing the pains of J2EE.

It looks

Answer 1

Which solution you go with also is dependent on how compliant you choose (or are required) to be with the Java EE spec. JPA is "the standard" for data access in Java EE systems, so if you're particular about adhering to that, you should use it (with some caveats).

JPA is a standardization of object-relational mapping systems. As such, it does not provide an implementation, it simply defines a standardized approach. Hibernate Entity Manager is one such implementation.

Since JPA is a standard across multiple vendors and since it is still fairly new, it lacks some more esoteric functionality that is valuable in some use cases (for example, a Criteria API for generating dynamic SQL). If you go with JPA plan on situations where you'll nee to use Hibernate directly, or even JDBC directly. For situations such as this, a generic DAO pattern is very useful; you can modify this one: Generic Data Access Objects for use in JPA & JDBC quite easily.

JPA has some difficult restrictions (particularly if you're used to Hibernate), and imposes certain approaches on you that are difficult for developers who are more used to writing straight JDBC. If you are championing this as an approach, be sure to do your homework about the pros vs. cons of ORM vs. JDBC.

If you go with JPA, once you've reached the learning curve it will pay off in terms of simple development (particularly if you properly implement the abovementioned DAO pattern), but also in getting multi-tiered caching of query results. If done properly (a big "if", I know), I have seen this provide handsome benefits.

Lastly, if you have a legacy data model that you have little flexibility with, Hibernate (and JPA) will give you more headaches than maybe worth. For example:

• If the database does not have candidate primary keys (for effective hashCode & equals implementations) you will need to do upfront analysis on which columns define a row uniquely -- maybe simple, maybe complex depending on the complexity of your schema;
• If you're unable to add version or timestamp columns, you lose Hibernate's ability to do optimistic locking, and end up having to query before updating.

(Added in response to first comment) If you're lucky enough to re-design your database, two very important considerations if you're going to be using an ORM:

• Add a version number column to all relevant tables to support optimistic locking.
• During your data analysis, decide on non-nullable "alternate key" column(s) that developers should use for hashCode() & equals(). Don't use PK columns in those methods.