Let's assume that PostalAddress is an object with a collection of fields
and that's it, no database entity.
Let's assume that Employee loads an address and places it into
PostalAddress which you can get using getPostalAddress(), and also
modify using setPostalAddress().
PostalAddress is serializable, not remote, thus, it behaves exactly like
getEmployeeName() setEmployeeName().
Further, PostalAddress can be presented as a separate table, or can be
in the same employee table, or can be shrink fit into one column, or
broken into more columns (e.g. addr_1, addr_2).
Assuming all that:
1. PostalAddress is reference by the bean as a dependent object
(Employee manages its life cycle)
2. PostalAddress is also used as a serializable object to get/set the
properties of Employees (a helper class)
The behavior of no.1 will not be affected if you decide tomorrow to add
setAddress(), setZipCode(), setCountry(), nor will the behavior of no.2
change it tomorrow employee actually contains address/zip/country fiels,
but you use PostalAddress for efficiently implementing
setAddress()/getAddress().
Thus, although you are mixing a helper class with a dependent class, you
are still using it for two different purposes, exactly as the specs
imply you should.
arkin
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
