I assume that would mean you will be looking at a top level object and
performing all the operations from that top level object. Which maps to
the entity bean. But that object can still contain a graph of objects
representing the detailed information, as long as the top level object
is where the create/find/remove operations and transaction control
occurs.
I found that approach to work better for a variety of other reasons. BMP
allows you to express your entities in such a fashion (at least, I
couldn't find anything to contradict it). CMP ... that's up to the
implementation.
arkin
> In the GemStone/Smalltalk we have a totally transparent distribution of fine
> grained objects between client and server (transparent replication and cache
> synchronization at transaction boundaries, etc). It is a beautiful thing
> from an oo design standpoint. However, we have found that in order to get
> larger systems to scale we have to introduce a services layer, and formalize
> what the client could do in the context of a transaction.
>
> Not everything we learned in the old days is bad! How does it go? Ignore
> history and your damned to repeat our past failings...
>
> Regards,
>
> -Chris.
>
> > -----Original Message-----
> > From: Laird Nelson [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 18, 2000 1:39 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Bean Granularity
> >
> > Chris Raber wrote:
> > > John,
> > > Our best practices team has documented some patterns in this area. We
> > tend
> > > to group Session Beans methods (services) by subject, sub-system or
> > > specialized service.
> >
> > The more things change, the more they stay the same: isn't this a good
> > rule of thumb that people apply to C programs/libraries? :-)
> >
> > And doesn't a lot of session bean design work smell like structured
> > analysis? And don't Entity beans feel a bit stinky, like ADTs? :-)
> >
> > 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".
--
----------------------------------------------------------------------
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".
