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