JDO Persistence, Part 1

Editor's note: In this first of three excerpts from Chapter 7 of Java Database Best Practices, author George Reese describes all the available persistence options for Java architects and developers, and provides data to help you choose the persistence option that fits the requirements and scale of your application.

Introduction

JDBC provides your application with direct access to a
relational data store. Though JDBC tries to objectify the data store using
objects that represent relational database concepts, it does not provide an
object-oriented picture of your problem domain. Your job in JDBC programming
is to use information from those database objects to build an OO picture of
your problem domain. This task is the problem of object-relational mapping we
talked about in Chapter 4, "Persistence Fundamentals".

Also in Chapter 4, I introduced the concept of the data access
object pattern. Using this pattern, business objects delegate their
persistence to something else called a data access object. Chapter 4 then
showed you how to use JDBC to build data access objects. Chapter 6, "EJB BMP," showed you
how to use the data access object pattern in an EJB system to provide
JDBC-based persistence.

You do not need to write the persistence layer for this pattern
to be valid. EJB CMP "delegates" its persistence operations to the container.
EJB CMP, however, is not the only automated persistence option for Java
architects and developers. This chapter covers the major standard option to
EJB CMP, the Java Data Objects (JDO) specification. If you are not familiar
with this specification, Chapter 12, "JDO," provides a tutorial to introduce you to
JDO programming.

JDO or EJB?

This question is actually too simplistic. Your persistence
options are much richer than JDO or EJB:

JDBC

JDO

Alternative persistence systems

Serialization

EJB CMP

EJB BMP + JDBC

EJB BMP + JDO

EJB BMP + alternative persistence systems

EJB BMP + serialization

Each of these options--even serialization--can be the right
answer for a particular persistence issue. EJB is overkill for small web
applications. Using EJB will kill the performance of your small application
and require significant effort to get initial functionality out the door.
JDBC, on the other hand, is a bad solution for a programming team with limited
database programming experience or with a significant number of persistent
objects to code. JDO, finally, is poorly suited to teams with little
understanding of transaction management or that require massive scalability.
Table 7-1 describes different problems and the persistence mechanisms best
suited to them. It is definitely not comprehensive and does not address the
advantages of alternative persistence systems.

BEST PRACTICE:

Do not use a one-size-fits-all approach to persistence--choose the persistence option that fits the requirements and scale of your application.

Table 7-1: Sample applications and matching persistence models

Application

Persistence model

Rationale

Embedded PDA phone book

JDO

Enables the development of a persistent application with the lightest footprint besides serialization. Unlike serialization, however, the use of JDO preserves object relationships in the data store.

Enterprise CRM system

EJB + EJB 2.0 CMP

Supports the scalability needs of a massive enterprise system while hiding the complexities of transaction management and object-relational mapping. Also enables developers with less experience to be more productive in the development of the system--fewer bottlenecks created by architects and senior Java developers.

Medium-sized web application against a legacy database

JDBC

Provides the greatest ability to control the object-relational mapping for an application with light transactional and scalability demands.

Massive web application against a legacy database

EJB + JDBC

Provides the greatest ability to control the object-relational mapping for an application with heavy transactional and scalability demands.

Massive web application with a gradual migration from a legacy data store to a new data store

EJB + JDBC and JDO

Enables control over object-relational mapping in the short term with the advantages of automated persistence for simpler components while avoiding mixing CMP and BMP models.

Swing application that needs to save its state across executions

Serialization

Supports quick storage and retrieval of the JavaBeans representing your application state with none of the overhead of the other tools.

The issues in Table 7-1 are just the surface issues. In short, you really need to know your
problem domain and the pluses and minuses of each persistence mechanism in
order to choose the best tool to support your application. One of the purposes
of this book is, of course, to arm you with an understanding of the different
persistence options so you can make that decision for the systems you design
and build.

The most fundamental distinction between the two persistence
models, however, lies in the concept of transparency. In order to take
advantage of EJB persistence--whether BMP or CMP--you must adhere to the EJB
component model. Any components outside of that model cannot be made
persistent. JDO, on the other hand, enables you to make any user-defined class
persistent. In other words, the persistence model is transparent to the
developer. Though you do not write any persistence code under EJB CMP, you are
still writing your classes to adhere to the EJB CMP persistence.

BEST PRACTICE:

When not building your business objects to a specific component model such as Enterprise JavaBeans, design your business objects to the JavaBeans specification.

Next week, in part two in our series of excerpts from Chapter 7 ("JDO Persistence"), George Reese covers basic JDO Persistence best practices, including transaction management and query control.