Java Database Access - JDBC, iBATIS, Hibernate Core, OpenJPA and PureQuery

Java Database Access API

• JDBC is good for applications in which the queries are dynamic and you need programmatic control of various tuning features to maximize performance. However, as the coding examples show, JDBC is relatively complex to use because you have to code the persistence logic yourself.

• iBATIS does a great job of insulating your object programmers from the details of JDBC and SQL by providing some ORM functions and keeping the SQL in a separate config file—especially applications that are based heavily on Stored Procedures or well-architected SQL from a DBA. However, if you prefer not to explicitly code SQL or if your domain objects have a complex life cycle, then iBATIS is not likely the best choice for you.

• Hibernate Core has a much more advanced ORM layer and has served as the basis for the new JPA standard; however, developers should begin to use the Hibernate JPA APIs if standards are important. Also, if you are using the JBoss Application Server, using Hibernate Core is a natural choice.

• OpenJPA, like Hibernate, has an excellent ORM layer that lets your Java programmers think in object terms. It has the additional advantage of being based on an industry standard and the capability to annotate the code and forgo the need for a mapping XML. ISVs may find the Apache license a better option for shipping software solutions based on OpenJPA. In addition, if you are using the WebSphere Application Server or WebLogic Server, using the OpenJPA-based runtime shipped with their container makes the most sense.

• pureQuery enables relational queries to be embedded in the Java code itself; however, it is relatively new as of publication and may undergo a number of changes that could impact code you write today. That said, it can have major advantages from a performance and tracing standpoint, especially if using DB2. Furthermore, pureQuery can be used in other types of environments, such as Web 2.0-based environments. Like iBATIS, applications that are based heavily on stored procedures or SQL written by a separate role such as a DBA should consider pureQuery as well. It is also worth noting that another persistence mechanism, such as the Groovy API's in Project Zero, may choose to implement on top of the pureQuery engine to exploit the performance and management features.

Some architects will not be willing to make the trade-offs associated with each of these mechanisms and will instead use this knowledge as an excuse to invent their own persistence framework exactly tailored to their requirements. Although inventing your own persistence layer can be fun, especially for architects with a strong computing science background, we advise against doing so because it puts your programmers in the middleware business instead of developing mission-critical enterprise applications.