-- Francis Pouatcha MATHEMA Software GmbH http://www.mathema.de
see inline. Laird Nelson wrote: > 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. "B is accessed only by A" doesn't mean that A schouldn't pass B to another bean and it is still true since helper classes are (theoritically) passed by copy. If the client changes somtehing on it copy of B, it must call some sort of A.setB( B) to allow A to commit that changes on the original copy of B. > 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. Let's better say other programs can change the original copy of B only indirectly through A. If i.e. B represent a row into the DB, the only copy of be the influences this row is the one owned by 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. postAddr ist passed by copy and thus e and it's client don't share the same reference to postAddr. The copy of postAddr owned by e is a dependent object of e. > > > 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. I beleive it is OK. Regards. -- Francis Pouatcha MATHEMA Software GmbH http://www.mathema.de
