If "home" methods other than create and find are allowed, you can easily
provide support for scenarios or "views" on your entity universe. These user
methods would simply return arbitrary java types encapsulating such
scenarios or views. The returned values can be one-shot results, session
bean references (reusable by the same client), entity bean references
(reusable by multiple clients) or a mix of the above.
IMHO, it is far more desirable to be able to add methods to an entity (home)
than to have to create additional session beans.
Imre Kifor
Valto Systems
-----Original Message-----
From: Richard Monson-Haefel <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, May 13, 1999 12:50 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".
