Building Java Enterprise Applications Volume I: Architecture phần 3 pot

Building Java™ Enterprise Applications Volume I: Architecture

59

Example 4-1. The EntityAdapter Helper Class

package com.forethought.ejb.util;

import javax.ejb.EntityBean;

import javax.ejb.EntityContext;

public class EntityAdapter implements EntityBean {

protected EntityContext entityContext;

public void ejbActivate( ) {

}

public void ejbPassivate( ) {

}

public void ejbLoad( ) {

}

public void ejbStore( ) {

}

public void ejbRemove( ) {

}

public void setEntityContext(EntityContext entityContext) {

this.entityContext = entityContext;

}

public void unsetEntityContext( ) {

entityContext = null;

}

public EntityContext getEntityContext( ) {

return entityContext;

}

}

If you have any implementation classes that need to provide special behavior for a callback,

you can override the adapter class; overriding still allows you to leave out any callbacks that

are not implemented, keeping code clean. In addition, I've introduced the

com.forethought.ejb package in this class. All the entity beans created for the example can

be put into this base package, in a subpackage using the bean's name (for example, office or

user), with the EntityAdapter class in the util subpackage of the same structure. So entity

and session beans end up prefaced with com.forethought.ejb.office or

com.forethought.ejb.shoppingCart. This is the same naming scheme you'll see in Sun's

PetStore and most other enterprise applications.

In addition to package naming, I follow standard practices for the actual bean class names.

This entails using the actual name of the data object as the name of an entity bean's remote

interface. In the case of an office, the interface name simply becomes Office. The home

interface has "Home" appended to it, resulting in OfficeHome, and the bean implementation

itself gets the word "Bean" added to it, resulting in OfficeBean. And with this last detail

covered, you're ready to move to the bean code for the office classes.

Building Java™ Enterprise Applications Volume I: Architecture

60

4.2.2 The Remote Interface

Once the naming has been determined, it is simple to code the remote interface, which is

always a good starting point in EJB coding. In this case, coding the remote interface is a

matter of simply providing a few accessors and mutators[2] for the data fields in the office

structure. Additionally, you should notice that no methods are provided to modify the ID of an

office. That data is intrinsic to the database and is used in indexing, but has no business

meaning; as a result, it should never be modified by an application. The only time this

information is ever fed to an entity bean is in the finder methods, where an office is located by

its primary key (findByPrimaryKey( ) in the home interface), and in the creation of an

office, where it is required for row creation (the create( ) method in the remote interface).

I'll look at this in Chapter 5 and discuss how you can avoid even these situations of directly

dealing with a database-specific value.

Additionally, you will notice that the ID of the office is returned as an Integer, instead of the

Java primitive int type. An Integer is returned for two important reasons. First, CMP 2.0

introduces container-managed relationships (sometimes called CMR, or CMP relationships).

This is a way of letting an EJB container manage relationships between entity beans (like the

Office bean here, and the User bean in Appendix D). When these relationships are used, the

container is responsible for generating additional classes to handle them, similar to a container

generating implementation classes for your CMP beans. When these classes are generated,

though, most containers make several assumptions; the first is that the primary key value on

an entity bean is stored as a Java object (java.lang.Integer), and not as a primitive type

(int). While this is not true in all EJB containers, it is in most. For this reason alone, it is

better to use Integer instead of int when dealing with primary key types.

Using an Integer with primary keys also has a nice side effect. Because Java programmers

are almost always more accustomed to working with the int data type, using Integer makes

the primary key value stand out. The result is that developers think a little bit more about

working with the value, resulting in primary keys being handled with care, as they should be.

Therefore, you will note that the getId( ) method in the remote interface of the Office bean

returns an Integer, not an int, and the create( ) method in the bean's home interface

requires an Integer as well.

Something else to note is the apparent naming discrepancy between the database columns and

the entity bean. You can see from Figure 4-1 that the primary key column in the database is

OFFICE_ID, and the field name, as well as related methods, in the Java class is simply ID (or

id as a method variable). This discrepancy may seem a little odd, but turns out to be perfectly

natural. In the database layer, simply using ID as the column name can result in some very

unclear SQL statements. For example, consider this SQL selecting all users and their offices:

SELECT FIRST_NAME, LAST_NAME, CITY, STATE

FROM USERS u, OFFICES o

WHERE u.OFFICE_ID = o.OFFICE_ID

2 Throughout this book, the terms accessor and mutator are used; you may be more familiar with the terms getter and setter. However, as I'm a dog

person, and my wife is a veterinary technician, we both realize that a setter is an animal, not a Java term. So an accessor provides access to a variable

(the getXXX( ) style methods), and a mutator modifies a variable (the setXXX( ) style methods).