Sorry, this is not quite right. getSummaryInfo and getInfoAboutTop10 should be in a session bean. getTop10 would be in the home. Getting the "info" is an application view, as "info" will change according to your particular use case. > -----Original Message----- > From: Tim Shephard > Sent: Thursday, May 13, 1999 3:42 PM > To: 'A mailing list for Enterprise JavaBeans development' > Subject: findLargeAccounts - do bother! (was Re: findLargeAccounts - > why bother?) > > 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".
