A getSummaryInfo() method in an entity should suffice. In fact, I now understand why findLargeAccounts works. but my particular problem is significally different from findLargeAccounts(and therefore was a bad example). The results of findLargeAccounts will be shared, thus caching (assuming, hah hah, you have caching) will take care of the various issues I mentioned. However, I think findLargeAccounts is actually a rare case. More likely is some particular specific use-case query such as findAccountsMatchingThisSpecification which is parameterized and mostly disjoint from query to query. The point about the CMP (we use BMP) was mostly ignored. Having to break the encapsulation CMP in order to get these runtime efficiencies seems to me to be a huge opportunity for 2.0. > -----Original Message----- > From: Imre Kifor [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, May 13, 1999 2:53 PM > To: [EMAIL PROTECTED] > Subject: Re: findLargeAccounts - why bother? > > >The collections of lightweight summary objects we are discussing are > >serialized and sent to the client requesting them, they do not remain on > the > >server as any kind of state. They contain the information that the actor > >uses to identify a particular entity that they would like to work with, > >typically. > > Why create a session object for the above if there is no client specific > state to keep? Just to host the methods? EJB already provides an entity > home > object that manages the associated entity universe. The point is that > these > type of summary or "collective" methods (that, again, are *not* client > dependent) should be part of the entity home. BTW, you don't have to > separate class static behavior into another class when writing java > classes. > > >They also contain the PK of the entity bean that they represent. > > Summary info of entities represents a specific member of the same > entities? > > >These objects are not domain objects, but are designed to contain the > >information needed by a particular actor in a particular use-case, and > >therefore belong in the application model layer. > > Which objects? If they represent (or depend on) a specific client then > absolutely yes. Otherwise, I just cannot see how summary info about the > top > 10 stocks of the stock universe would need to be modeled by session beans > unique to specific clients/actors. > > >If there are collections > >of domain objects that need to be provided to the client (as there most > >certainly are, including the examples you gave), then these collections > >should be made available through the interface of the relevant entity > bean. > > > Do you mean "getInfoAboutTop10" should be part of the Security entity > bean's > remote interface (as opposed to the home interface)? > > Imre Kifor > Valto Systems > > ========================================================================== > = > 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".
