I (along with many others on this list) am a big fan of wrapping (also known
as encapsulating) entity beans with session beans. This approach simplifies
programming for the client (you only have to find one object) and increases
performance and scalability (you use fewer resources).
In many applications, the client wants to look at a list of stuff, then
operate on individual entities within that list. The client often operates
on a subset of the list, therefore you frequently don't want to instantiate
all of these entities. Therefore it makes sense to generate the list in the
session bean using a simple JDBC query. It might be nicer if you could
create the list through the entity bean home interface, but we don't have
that capability now.
Chances are high that a number of different applications may want to
retrieve lists of a particular entity bean, so rather than duplicating the
code in many session beans, you could build a single session bean that's
responsible for generating the lists for all applications. Yes -- you have
two beans that encapsulate this data source, but at least you limit yourself
to two. One deals with collections (this bean could also perform reporting
and analysis for you), the other deals with individual entities.
There are three points here:
1- from the client's point of view, all the data that it needs to work with
is encapsulated by it's primary session bean (the one that represents this
particular client on the server).
2- a bean that manipulates collections of data is inherently different from
a bean that manipulates a single entity instance.
3- do what makes sense for your specific application. We all try to design
databases according to third normal form, but we often denormalize the
design for performance reasons. Sometimes we need to do the same for our
object design.
-----Original Message-----
From: Richard Monson-Haefel [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 13, 1999 12:46 PM
Subject: Re: findLargeAccounts - why bother?
Perhaps lists that are specific to one entity should be included in the
entity business logic. However, summary data or reporting data spans
entities and is not reusable across scenarios should not be in the entity
bean (or its home). Why would you encapsulate a summary in the entity bean
if it is only used in one scenario? What is the value of that besides
creating hopelessly bloated entities. If you use direct database access to
produce a summary from a session bean, then you are encapsulating that
behavior in the session. I realize that my approach breaks persistence
independence, but come on. Were also trying to make systems that perform.
-----Original Message-----
From: Ian McCallion [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 13, 1999 8:46 AM
To: [EMAIL PROTECTED]
Subject: Re: findLargeAccounts - why bother?
Richard Monson Haefel wrote:
>I have a different view point from Ian's. Most listing and summary data
is
>propriate 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.
I must have higher aims for encapsulation than Richard! To me
"encalsulating" the data inside two beans is not encapsulation.
Also, I believe that summary extraction will quite often be reusable.
Indeed one could imaging providing a general query service in which the
selection criteria and fields needed could be passed as parameters.
Ian McCallion
===========================================================================
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".
