Laird Nelson wrote:

 > 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.

In this case the client is creating a postAddr object, but it's
not creating the *persistent* postAddr object, which would be
created either via the JDBC insert (or via an entity bean if we
were using one, but we're not in this case).  The Employee bean
has control over the actual creates, updates, and deletes of
the persistent (database) instances of the dependent objects.

The postAddr is acting as a value object.  Presumably the
Employee entity bean in the setAddress method picks the data
from the supplied postAddr object and inserts it into the
database.  It would probably be better to use some sort of DAO
helper classes, but that's just an implementation detail.

The value object is an often-used EJB design pattern, which is
an extension of the GOF memento pattern.  A value object can
return the fields for an EJB in one package, or as in this case,
it can also package dependent objects as well.  This site:
http://www.c2.com/cgi/wiki?EjbRoadmap has a catalog of EJB
design patterns.

 > 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.

Sure.  Or perhaps a PostalAddress is created on the fly and
returned each time getAddress is called.  That just depends if
you want to hold onto the object or not.  If the entity bean
holds onto one, just make sure that the PostalAddress object
is synchronized with the database at the same time that the
EmployeeBean is, or they might get out of synch with each
other.

-Paul Hodgetts

===========================================================================
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".

Reply via email to