Java Reference
In-Depth Information
"knows" about its related object. For example, if
CourseEJB
knows which
StudentEJB
instances it
has and, at the same time,
StudentEJB
knows which
CourseEJB
it is associated with, they have a
bidirectional relationship.
In a
unidirectional
relationship, only one entity bean has a relationship field that refers to the other. Look
at the snipet of the deployment descriptor given on the previous page;
YachtEJB
has a relationship
field that identifies
EngineEJB
, but
EngineEJB
does not have a relationship field for
YachtEJB
. In
other words,
YachtEJB
knows about
EngineEJB
, but
EngineEJB
doesn't know which
YachtEJB
instances refer to it.
EJB QL queries often navigate across relationships. The direction of a relationship determines whether
a query can navigate from one bean to another. For example, a query can navigate from
YachtEJB
to
EngineEJB
but cannot navigate in the opposite direction. For
CourseEJB
and
StudentEJB
, a query
can navigate in both directions, since these two beans have a bidirectional relationship.
Access to Relationship Field
During development, you implement the relationship fields in a similar way to persistent fields. They are
defined in the deployment descriptor, and they have their
getters
and
setters
defined in the bean-
implementation class. They can even be exposed in the remote interface. By following a strict syntax for
authoring relationship fields in the bean-implementation class and in the deployment descriptor, the EJB
container is able to implement the relationship automatically behind the scene.
The rules for writing relationship-field
accessor
methods in a bean-implementation class are listed
here:
Both
getters
and
setters
for every relationship field must exist in the implementation class.
These
getters
and
setters
must be declared as abstract and must contain no implementation
code.
These
accessor
methods must begin with
get
or
set;
and the text following
get/set
must
match the name of the relationship field as it is declared in the deployment descriptor.
These
getters
and
setters
that do not access
Collections
may be optionally placed in the
remote interface.
If you want the clients to use the relationship-field
accessor
method, put the
getters
or
setters
in
the remote interface. But the last rule says that you may only do this if the method does not access a
Collection
of objects. Only the entity bean's other business methods can use its own
Collection
relationship.
Why does such a restriction exist? It is imposed for better performance. For a one-to-many relationship,
a
getter
may return a
Collection
of the related EJB objects. For example, the
OrderEJB
and
LineItemEJB
are linked by
lineItem
field of the
OrderEJB
. The
getLineItems()
method may
return tens or hundreds of
LineItemEJB
instances, but you may want to work only on one of these
LineItemEJB
instances. Imagine the network traffic it produces! To avoid the potential performance
nightmare, the last rule given in the preceding list is imposed. If you really need to get the whole list of
the elements to the client, you must define your own (nonabstract) utility
accessor
method like this:
Public ArrayList getAlLineItems() {
ArrayList list = new ArrayList();
// call the abstract relationship field accessor and walk through the
Collection
Iterator iter = getLineItems().iterator();
While (iter.hasNext()) {
List.add(iter.next())
}
}
