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".
