Imre, are these collection "beans" available to the developer community
separate from your EJB container?
jim
----- Original Message -----
From: Imre Kifor <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 14, 1999 10:07 AM
Subject: Re: findLargeAccounts - why bother?
> I agree with your three points. Supporting your second point, I would like
> to add that we have been very successfully modeling collections of entity
> beans through a generic "collection" entity bean (EJBCollection, EJBSet,
> EJBTree etc.). Since they are not session beans, they can be shared by
> multiple clients (Note: session beans are just as expensive (!) as entity
> beans and require more server side processing to support timeouts).
>
> Our EJBCollections and their implementations can also be subclassed. Using
> this approach, we can easily create "Fund", "Portfolio", "Assets",
> "Industry" etc. beans as collections of "Security" beans in our financial
> application. All the collection manipulation operations and even our SQL
> statements for CMP can all be shared by both the pre-defined business
> "beans" and the ad-hoc, "what-if" scenario implementations. The ad-hoc, on
> demand generated collection entity objects use the query criteria as their
> PKs, hence they can be cached and shared with no effort.
>
> Imre Kifor
> Valto Systems
>
> -----Original Message-----
> From: Anne Thomas <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Friday, May 14, 1999 9:34 AM
> Subject: Re: findLargeAccounts - why bother?
>
>
> >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".
> >
>
>
===========================================================================
> 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".
