Which would you choose to use as your persistence framework?

JDO (Java Data Objects)
Hibernate
?

Why? Trying to get some ideas on what we should use with our J2ee persistence layer. We're using STRUST as our applicaiton layer and Java Blueprints as out business layer design

Hi Katherine,

There are some decisions you need to make about how you want to implement your persistence tier and this will tend to drive your choice of technology.

First of all, are you designing an application that will always run in a J2EE application server? If not then you will need to use JDBC or JDO, or a proprietary framework such as Hibernate. Before I get flamed for calling Hibernate "proprietary" I should point out that I am using the term to mean "not a core part of the Java platform" as with JDBC, JDO, or J2EE.

Another decision is whether you want to have an isometric mapping where each Java class represents a single Table or whether you want to use idiomatic Java and make full use of object-orientation and have "transparent persistence". The former case is simpler and can be achieved using the Data Access Object (DAO) design pattern which also provides an abstraction from the underlying technology (for example, DAO can be implemented using JDBC, JDO, and Entity Beans).

If you want transparent persistence then JDO or Entity Beans would be more suitable.

These are just some initial pointers... there are also performance considerations to be taken into account.

You may want to consider using a tool like FireStorm/DAO from CodeFutures to import your database schema (or design a new one) and then generate your persistence tier using JDBC, JDO, or Entity Beans so you can compare the code and the performance of each one. You can download a free evaluation from:

http://www.codefutures.com/products/firestorm

Hope that helps.

Andy Grove
Code Futures, Ltd.
http://www.codefutures.com

Katherine,

Before I try to help answer your question I want to make a suggestion. Don't try to compare Hibernate with JDO. If you do, you are comparing an individual framework with a specification used to create many frameworks.

Instead, examine carefully what is important to you (scalability, performance, a standards based framework, vendor choice, support, etc). Also consider the following: How complex is your object model, Will you need to map from an existing database schema?, Do you need runtime tools for performance tuning? Will you want something that will work both inside and outside the container? Will you always be persisting to RDB's or do you have other needs like flat files or XML? Then once you know thyself start to compare existing persistence frameworks and see how they stack up to eachother.

My suggestions is that you start your quest fwith this whitepaper by Mick Jordan from Sun.

http://research.sun.com/techrep/2004/abstract-136.html

The right solution will be defined by your needs and expectations.

By the way, I work for SolarMetric and I am very bias. This makes me unqualified to tell you which path to take. I can however tell you what our path looks like and where it is going.

Good luck in your search,

Robert Monaco
Kodo Evangelist
Check us out at www.solarmetric.com