Choosing to Manage Persistence Yourself

For every entity bean you develop, you have the option to write the database access code to manage its persistence yourself. The other choice is to define mappings between your bean's fields and the database and put the responsibility on the container to keep your bean and the database in synch. This chapter looks at what you have to do to manage a bean's persistence yourself. The two chapters that follow look at what you do to let the container do more of the work for you.

Most of this chapter is focused on the mechanics of implementing a bean using bean-managed persistence (BMP). You'll learn what you're expected to do within each of the callback methods that were introduced in the preceding chapter. Before doing that, though, it's important to consider what the implications of using BMP are and how to determine when it's an appropriate choice. EJB 2.0 in particular places a strong emphasis on container-managed persistence (CMP), so before starting down a path of using BMP, you should have a solid reason for doing it.

When you use BMP to implement an entity bean mapped to a relational database, you either write JDBC code or use a framework, such as WebGain's TOPLink for Java or CocoBase Enterprise O/R from THOUGHT Inc., to implement the required database access code. Your code and that in any framework you might use have precise control over the SQL that is generated to maintain your persistent objects. This trait points out both the good and the bad about BMP. Because this approach gives you complete control over the SQL that's generated, BMP is most useful when you need to do something that the CMP implementations available to you don't support. You have full flexibility in persisting an entity in any way you see fit. The obvious disadvantage is that you're responsible for writing and maintaining more code when you do this. You have to rely more on the code within a bean than on the declarative mappings used with CMP that can be modified at deployment without changing code.

In general, BMP has the potential to be more error-prone than CMP. It's never easy to admit that you write defective code at times, but everyone does it. It's also true that it isn't easy to uncover the most reliable and efficient solution to a problem when you're working in areas in which you don't have extensive experience. This is why much of the evolution in software development has been based on raising the bar on what you have to write yourself. Often the best way to reduce errors is to write less code. The Java API provides classes that keep you from having to reinvent the wheel when you need to do a lot of the common tasks of developing an application. When you use these classes, you have a tested foundation to build on and you can focus more on the parts of the application you understand in depth. EJB takes this same concept further by providing a foundation for building distributed applications. CMP goes one step more to reduce the coding tasks you have to do to persist your data. BMP requires you to write more of the code yourself so it increases the risk of coding errors.

When you use BMP, it's more difficult to code beans that are independent of a particular database or application server. Even though JDBC protects you from most of the differences between database platforms, you'll still run into some issues if you have to use unique features such as automatic primary key generation. You also must be careful about managing table and column names so that simple schema changes don't ripple throughout your code. It's natural that having more of your persistence details show up in your bean code makes your beans less adaptable.

Even with its faults, you shouldn't view BMP as a bad approach to take. In fact, many EJB developers would argue that the benefits of BMP make up for any shortcomings it might have. This is especially true as CMP implementations are still trying to evolve to the point of being robust and portable. Many of the drawbacks of BMP can be addressed if you use an object-to-relational mapping (ORM) framework instead of directly coding JDBC calls within your beans. For example, TOPLink can maintain the mappings between class fields and database columns external to your code for BMP as well as CMP. This means that you're isolated from simple schema name changes. A framework such as this also manages differences between database platforms for you. You might have to lock yourself into a particular ORM framework to some extent, but the resulting portability across databases might be worth it. A BMP approach like this can often give you more portability than CMP. EJB 2.0 is looking to change this by adding container-managed relationships between entity beans and common finder method definitions to the standard features offered by vendors .

The debate between BMP and CMP has experienced developers on both sides. If the CMP implementations available to you for your particular application server just won't do what you need, then it's a somewhat easy choice to use BMP. Before doing this, be sure you've considered any third-party CMP implementations that support your application server.

ORM Frameworks and BMP

If you implement an entity bean using BMP, you can take the approach of using an ORM framework or you can use JDBC directly. ORM products, such as TOPLink and CocoBase, provide a Java API that allows you to persist objects using method calls on Java objects. You define mappings between your persistent classes and the database tables using a tool provided by the vendor. These mappings are then used at runtime to translate from the object world to the relational database world. Under the hood, Java ORM frameworks are still using JDBC to talk to the database, but they hide the details of the SQL from you unless you need to define a custom query.

Every ORM vendor that supports BMP has its own API for doing it. This is one of the few drawbacks to using one of these tools. The uniqueness of APIs also makes it impracticable to cover the details of using an ORM framework for BMP in this book. If you do choose to use one, your vendor's documentation will cover what you need to know to use it for BMP. This chapter focuses on how to use JDBC to implement a BMP solution, but you'll find that a lot of the issues apply even if you're using an ORM product.