I'm building a session bean facade for my
entity beans, and need to return a collection
of updateable "rows" of data showing only
some of the attributes from some of my
underlying entities for the client interface.
In fact it's kind of a "join" of the data
from two underlying entity beans that needs
to be returned.

When using an approach to return a collection
of hand-coded struct-like value objects, what is the
best practice technique to allow the client of
my session bean to make updates to any or all
of the attributes being passed in the value object?

I read conflicting reports in books that alternate
between suggesting that:

   -> Value objects should be immutable to not
      give the false impression that calling
      setSalary() -- for example -- actually
      goes and sets the underlying entity bean.

and

   -> Value objects should have get/set methods
      (i.e. be mutable). In fact some books suggest that
      my entity bean inherit from the value object.

In any event, do I need to provide additional
remote methods on my session bean facade which
accept one of these hand-coded struct-like value objects...

   updateEmployee( empValueObject );
   updateEmployees( Collection ); // Of empValueObject's

and then inside the implementation of this bean method
write code that transfers the values back into the
appropriate underlying entity bean inside the middle tier?

If the client passes me a collection of these, what is a
best-practice technique of determining which of the
value objects have been changed by the client? or is it
the client's responsibility to only pass me one's that
have changed or been added?

Thanks in advance,

Steve

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