Tim Shepard wrote:
> Say you wanted to show the large accounts in a client side Table GUI
> component.
>
> The original take on this was that querying for the Primary Keys,
returning
> the primary keys, and then getting each primary key in turn from the
> AccountHome was horrendously expensive.
>
> Rather we saw that one call to a session bean which created helper
> objects(basically a lightweight table row version of the Account bean)
from
> one SQL select statement which return them in a collection of some sort
was
> much more realistic.
>
> The second take was that it was a session bean that talks back and forth
to
> the entity bean, so bandwidth wasn't a terrible problem.
>
> 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
CICS Business Unit
IBM Hursley
[EMAIL PROTECTED]
Tel: ++44-1962-818065
Fax: ++44-1962-818069
===========================================================================
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".
