7.1 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.