The EJB specification states, on page 99 (that's 103 in your Acrobat
reader):
"A dependent object can be characterized as follows. An object B is a
dependent object of an object A, if B is created by A, accessed only by
A, and removed by A. This implies, for example, that if B exists when A
is being removed, B is automatically removed as well. It also implies
that other programs can access the object B only indirectly through
object A. In other words, the object A fully manages the lifecycle of
the object B."
The examples given strike me as not supporting this. The examples are
as follows:
"For example, a purchase order might be implemented as an entity bean,
but the individual line items on the purchase order should be
implemented as helper classes, not as entity beans. An employee record
might be implemented as an entity bean, but the employee address and
phone number should be implemented as helper classes, not as entity
beans."
Let's look at the second example.
Suppose Employee has a setAddress(PostalAddress a) method. (Suppose
that Employee is an entity bean.) So the client would do something like
this:
Employee e = // get it from somewhere
// note that client is the one doing the creation here
PostalAddress postAddr = new PostalAddress("123 anywhere street");
e.setAddress(postAddr);
In this example, the client creates postAddr and assigns it to
Employee. By the definition given above, since e does not create
postAddr, postAddr is not a dependent object of e. Does that mean that
postAddr should be modelled as an Entity bean? Surely not.
Is it OK in this example to make PostalAddress be a simple plain-Java
serializable object that EmployeeBean maintains a reference to? I sure
hope so.
Cheers,
Laird
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
