As discussed in the previous section, dependent value classes are custom serializable objects that can be used as persistence fields—(although this use is not recommended). Dependent value classes are useful for packaging data and moving it between an entity bean and its remote clients. They separate the client’s view of the entity bean from its abstract persistence model, which makes it easier for the entity bean class to change without impacting existing clients.
The remote interface methods of an entity bean should be defined independently of the anticipated abstract persistence schema. In other words, you should design the remote interfaces to model the business concepts, not the underlying persistence programming model. Dependent value classes can help separate a remote client’s view from the persistence model by providing objects that fill the gaps in these perspectives. Dependent value classes are used a lot in remote interfaces where packaging data together can reduce network traffic, but are less useful in local interfaces.
For example, the CustomerEJB
could be modified so
that its lastName
and firstName
fields are not exposed directly to remote clients through their
accessor methods. This is a reasonable design approach, since most
clients access the entire name of the customer at once. In this case,
the remote interface might be modified to look as follows:
import java.rmi.RemoteException; public interface CustomerRemote extends javax.ejb.EJBObject { public Name getName() throws RemoteException; public void setName(Name name) throws RemoteException; }
The remote interface here is simpler than the one we saw earlier. It
allows the remote client to get all the name information in one
method call instead of two—this reduces network traffic and
improves performance for remote clients. The use of the
Name
dependent value is also semantically more
consistent with how the client interacts with the Customer EJB.
To implement this interface, the CustomerBean
class adds a business method that matches the remote interface
methods. The setName()
method updates the
lastName
and firstName
fields,
while the getName()
method constructs a Name
object from these fields:
import javax.ejb.EntityContext; public abstract class CustomerBean implements javax.ejb.EntityBean { public Integer ejbCreate(Integer id){ setId(id); return null; } public void ejbPostCreate(Integer id) { } // business methods public Name getName() { Name name = new Name(getLastName(),getFirstName()); return name; } public void setName(Name name) { setLastName(name.getLastName()); setFirstName(name.getFirstName()); } // abstract accessor methods public abstract String getLastName(); public abstract void setLastName(String lname); public abstract String getFirstName(); public abstract void setFirstName(String fname);
This is a good example of how dependent value classes can be used to separate the client’s view from the abstract persistence schema.
The getName()
and setName()
methods are not abstract persistence methods, they are
business methods. Entity beans can
have as many business methods as needed. Business methods introduce
business logic to the Customer EJB; otherwise, the bean would be only
a data wrapper. For example, validation logic could be added to the
setName()
method to ensure that the data is
correct before applying the update. In addition, the entity bean
class can use other methods that help with processing
data—these are just instance methods and may not be exposed as
business methods in the remote interface.
How dependent value classes are defined is important to understanding
how they should be used. The Name
dependent value
class is defined as follows:
public class Name implements java.io.Serializable { private String lastName; private String firstName; public Name(String lname, String fname){ lastName = lname; firstName = fname; } public String getLastName() { return lastName; } public String getFirstName() { return firstName; } }
You’ll notice that the Name
dependent value
class has get
accessor methods but not
set
methods. It’s immutable. This is a
design strategy used in this book, not a requirement of the
specification; CMP 2.0 does not specify how dependent value classes
are defined. We make dependent values immutable so that “remote
clients cannot change the Name
object’s
fields. The reason is simple: the Name
object is a
copy, not a remote reference. Changes to Name
objects are not reflected in the database. Making the
Name
immutable helps to ensure that clients do not
mistake this dependent value for a remote object reference, thinking
that a change to the Name
object is automatically
reflected in the database. To change the customer’s name, the
client is required to create a new Name
object and
use the setName()
method to update the Customer
EJB.
The following code listing illustrates how a client would modify the
name of a customer using the Name
dependent value
class:
// find Customer customer = home.findByPrimaryKey(primaryKey); name = customer.getName(); System.out.print(primaryKey+" = "); System.out.println(name.getFirstName()+" "+name.getLastName()); // change Customer's name name = new Name("Monson-Haefel", "Richard"); customer.setName(name); name = customer.getName(); System.out.print(primaryKey+" = "); System.out.println(name.getFirstName()+" "+name.getLastName());
The output will look like this:
1 = Richard Monson 1 = Richard Monson-Haefel
Defining the bean’s interfaces according to the business concept and not the underlying data is not always reasonable, but you should try to employ this strategy when the underlying data model doesn’t clearly map to the business purpose or concept being modeled by the entity bean. The bean’s interfaces may be used by developers who know the business but not the abstract programming model. It is important to them that the entity beans reflect the business concept. In addition, defining the interfaces independently of the persistence model enables the component interfaces and persistence model to evolve separately. This allows the abstract persistence programming model to change over time and allows for new behavior to be added to the entity bean as needed.
While the dependent value classes serve a purpose, they should not be
used indiscriminately. Generally speaking, it is foolish to use
dependent value classes when a CMP field will do just fine. For
example, checking a client’s credit worthiness before
processing an order can be accomplished easily using the
getHasGoodCredit()
method directly. In this case,
a dependent value class would serve no purpose.
Please refer to Workbook Exercise 6.2, Dependent Value Classes in CMP 2.0. This workbook is available free, in PDF format, at http://www.oreilly.com/catalog/entjbeans3/workbooks.