Laird,
I am with you on Entity Beans being a tad stinky (too closely modelled after
relational constraints, and mapping of coarse grained beans in CMP in
insufficiently defined in the spec).
But, Session Beans don't necessarily smack of structured analysis. It is
more that the practical reality of distributed systems forces us to define a
more rigid "services" layer than pure abstract oo modelling would suggest.
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".
