See below ...
Ian McCallion wrote:
> Tim Shepard wrote:
>
> >
> > The third take was that these entity beans are being created, when 99% of
> > them aren't going to be accessed except for the summary information. And
> it
> > still didn't seem realistic to do a 100 select statements (to load each
> > Account) versus just one (to just create the summary objects).
>
> Tim's third approach suffers from only one problem - lack of encapsulation.
> Clients need to know to ask different beans for summary and detail
> information, and the location of the data is held in two beans.
>
> A solution that addresses this is to allow class methods on Enterprise
> JavaBeans. These are similar to finders, but are allowed to return
> arbitrary information. Unfortunately the EJB spec does not support such a
> thing yet. I believe it should.
>
> Ian McCallion
>
I have a different view point from Ian's. Most listing and summary data is
specific to a scenario and is not generally reusable. For this reason I prefer
to use direct database access from a session bean that represents the
scenario. In other words, I agree with Tim's third option. I would say that
this is an appropriate strategy for 3 reasons: 1) Its more peformant to access
the database directly for read-only listing and summary data. 2) Encapsulation
is achieved through the session bean (to say its not is to say that entity bean
encapsulation is some how superior), 3) most listing and summary needs are not
reusable and should therefor not reside in the entity bean.
--
Richard Monson-Haefel
Senior Consultant
BORN Information Services
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
(Available June 1999)
===========================================================================
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".
