Jim, Can you please describe a usag scenario of this design pattern? Thanks, -Chris. > -----Original Message----- > From: Jim Frentress [SMTP:[EMAIL PROTECTED]] > Sent: Friday, May 14, 1999 1:30 PM > To: [EMAIL PROTECTED] > Subject: Re: findLargeAccounts - why bother? > > Last year we built our own version of what Imre's product does (no Imre, > we > didn't know about your stuff when we wrote ours). It's extremely similar > to > the Ejipt implementation (non-EJB's, extending jdk2 collections). I do > hope > that this stuff is available outside of Ejipt because I'll look into > offloading that part of our system and let Valto manage/enhance it ;) > > note that the Ejipt stuff probably requires jdk2 whereas ours does not (it > runs fine with the jdk1.1 collections implementation available from sun). > > I can say that our version performs excellently and it isn't that > difficult > to implement the basics if you wish to roll-your-own. > > > -----Original Message----- > > From: James Cook [SMTP:[EMAIL PROTECTED]] > > Sent: Friday, May 14, 1999 9:19 AM > > To: [EMAIL PROTECTED] > > Subject: Re: findLargeAccounts - why bother? > > > > 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". > > ========================================================================== > = > 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".
