What if some light weight business logic needs to be in the setXXX behavior?
For example an edit check from the client.

What about handling nested related objects? Would you advocate nested
hashmaps be returned to the client?

Is it more brittle for the client to have to know the names for the
name-value pairs? Or is it more brittle for the client to have to know
getXXX/setXXX method names?

Is it 6 of one or half dozen of the other?

-Chris.


> -----Original Message-----
> From: Doron Somer [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, July 21, 1999 2:17 PM
> To:   [EMAIL PROTECTED]
> Subject:      Re: fat getter/setters versus get/set with all data
>
> Going for a more flexible approach with a get and set methods that accept
> a
> set of name-value pairs, and use of reflection is preferrable.
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Terran Vigil
> > Sent: Wednesday, July 21, 1999 10:47 AM
> > To: [EMAIL PROTECTED]
> > Subject: fat getter/setters versus get/set with all data
> >
> >
> > For performance reasons, I've been thinking about replacing
> > my Entity Bean
> > getter and setter methods with fat .extractData() and
> > .setData() methods. At
> > the same time, I would create a serializable container class
> > that would wrap
> > only the properties of the EntityBean. This would:
> >
> > - eliminate a plethora of getter and setter methods that
> > clients can't call
> > anyway (I'm using the "SessionBean wraps EntityBean" model).
> >
> > - Prevent the EJB container from calling ejbStore() multiple times.
> > Actually, I guess this is only a problem if the EntityBean is
> > called without
> > a calling transaction.
> >
> > - Provide a data class for returning data to client since we
> > aren't going to
> > pass EJBObjects to client.
> >
> > What does everyone think? Anyone else doing this?
> >
> > Terran
> >
> > ==============================================================
> > =============
> > 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".

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