ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button O'Reilly Book Excerpts: Java Database Best Practices

JDO Persistence, Part 1

Related Reading

Java Database Best Practices
By George Reese

by George Reese

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.

George Reese is the founder of two Minneapolis-based companies, enStratus Networks LLC (maker of high-end cloud infrastructure management tools) and Valtira LLC (maker of the Valtira Online Marketing Platform). He is also the author of technology books such as the MySQL Pocket Reference, Database Programming with JDBC and Java, and Java Database Best Practices.


Return to ONJava.com.