Yes, this is where value-objects , bulk setters and dependent
objects meet.

Cheers,

Frank

> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Laird Nelson
> Sent: Tuesday, February 22, 2000 3:37 PM
> To: [EMAIL PROTECTED]
> Subject: More dependent class questions
>
>
> 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".
>

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