We live in a relational world - which is too bad since we develop with objects. Since most non-trivial applications require information to be persisted and retrieved in what is generically called a database, we need to find efficient methods for persisting our objects and retrieving them. Historically, this has been done with relational databases and lots of code that flattens the objects and maps them to the relational tables. This can be done in Java or with object-relational mapping tools like Hibernate.

While most books and articles about object-oriented software development discuss the benefits of using objects to describe the problem space, currently most development is done in a more convoluted manner, working from both the Java and database ends and using various technologies to bridge the gap between them. Hibernate has emerged as one of the most popular ways to address this development challenge.

Instead of starting with a database schema and building objects from the tables and data therein, this article will focus on starting with the Java objects and evaluate a few of the many options for persisting them. We will compare and contrast the methods, as well as discuss challenges and problems specific to object persistence management (see Table 1).

Options for Persisting Java Objects
There are many options for persisting your Java objects. Some are best used when your persistence needs are simple (such as saving program state between sessions) and some are better when your needs are complex (such as saving lots of data over long periods of time). Some applications simply need to load data for use in configuring the application, while others require sophisticated tools for searching and filtering object sets. The latter is typical for applications that use a database for persistence and will be the primary focus here. For each project you work on, you should evaluate which persistence strategy best fits your needs based on the project requirements. The following persistence mechanisms will be discussed in this article:
• Hibernate
- The most commonly used object-relational mapping tool
• DB4Objects DB4O
- A small simple embeddable object database
• InterSystems' Caché Database with Jalapeño
- An enterprise database that lets you store POJOs via its Jalapeño technology - but also provides a JDBC/SQL interface to the objects stored in the database

Please note that there are many other object-relational mapping solutions and object databases available, the purpose of this article is simply to provide some insight as to the benefits of using these technologies versus a JDBC/DAO implementation, how they compare and to how you can use them for your projects.

Definition: DataStore - A system for storing and retrieving data. Can be relational or object-oriented.

Object Persistence Mechanism Considerations
For each of the persistence strategies outlined above, I will review the following:
• Ease of Implementation
- How much preparation and/or configuration is required to persist your objects?
• Ease of Persisting Objects
- How do you persist an object or objects?
- Is it straightforward and intuitive?
- Is it better/simpler/faster than using SQL and writing DAOs?
• Ease of Retrieving Objects
- What mechanisms are available for finding and retrieving the objects in the datastore?
• Control over Object Depth
- How many objects do you want to save or retrieve at the same time?
• Control over Object Property Breadth
- How many properties do you need access to? Can you only return those properties?
• Object Tree Traversal
- Can you access all related objects and their properties simply by traversing the object tree?
• Enforcing Referential Integrity
- How do you ensure you don't delete an object that other objects depend on?
* For example, can you delete a department if employees still exist?
- Does it support cascade deletes/updates?
• Enforcing Uniqueness
- How do you ensure that specific properties are unique in the database, such as Social Security numbers?
• Support for Indices
- Can you define indices that will enhance the performance of your queries?
• Property Constraints
- Can you control/limit the values that will be entered into the datastore?
• Security and Access Control
- How do you control who has access to the data and what they can do with it?

Ease of Implementation
One of the things we're trying to get away from is the effort to write and maintain DAOs. So let's look at what's involved in setting up your datastore and prepping your POJOs to be persisted for each of the persistence mechanisms identified.

Hibernate
Hibernate has the most complex setup of the solutions discussed here, but it's not that bad and Hibernate does provide a lot of tools to make your life easier. There are multiple ways to implement Hibernate, but since we are starting the POJOs, we'll only consider the case of adding annotations to the Java class to support Hibernate persistence. If you're using Hibernate 3.2 with Java 1.5 or above, you can use annotations to map your POJO properties to your Table columns. Using annotations is much less verbose than defining your mappings in XML files and has the additional benefit of reducing the number of files you must keep track of. In addition to annotating your POJOs you need to provide the fully qualified name of the annotated class as a <mapping> element in the hibernate.cfg.xml file.

The minimal steps for preparing to persist your objects with Hibernate are:
1)  Set up a database and create a username and password for Hibernate to access it with
2)  Annotate your Java Classes
3)  Add your class mappings, database, and user/login information to the hibernate.cfg.xml file
4)  Run the Hibernate hbm2ddl to create the schema in the database

An example of mapping in the hibernate.cfg.xml file:

<mapping class="com.egrok.hibernate.Person"/>