While I agree that your controllers should be modeled through session beans
(they are meaningful only in the context of a specific client),
nevertheless, some aggregate characteristics of entity beans still belong to
the domain model.
Consider a financial application where stocks (securities) are modeled with
entity beans. Aggregate info about them (current value, combined performance
or the set of portfolios they belong to) is still part of the domain (i.e.
independent of the client looking at it). If you modeled this latter info
through session beans and you had 1000 clients, you would replicate the same
info in 1000 session beans whereas they could be shared just as easily. This
doesn't mean that you should never use session beans. An appropriate example
would be a "what if" scenario that is very unlikely to be shared by clients.
It is very misleading to say that all aggregate info about entity beans
should be modeled through session beans. We need a variety of tools and
allowing "user" methods in entity homes could be a rather useful one. And
one quite easy to use considering full CMP support.
I don't understand why you would want to create a session bean to implement
a method like "getTodaysTop10Performers()" or "getInfoAboutTop10".
Especially when you may have 1000's of users asking the same question at the
same time.
Imre Kifor
Valto Systems
-----Original Message-----
From: Chip Wilson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, May 13, 1999 1:52 PM
Subject: Re: findLargeAccounts - why bother?
>There is an even more compelling reason to place the creation/retrieval of
>collections of summary objects in a session bean rather than an entity
bean.
>Summary objects are part of the application model layer of the
architecture,
>not the domain layer. Entity beans are appropriately placed in the domain
>layer, as coarse-grained facades to the domain model. Session beans, on
the
>other hand, are appropriately placed in the application model layer, as
>use-case controllers and the implementers of the application's system
>operations. The creation of summary objects, being a responsibility of the
>application model layer, is most appropriately placed in a session bean.
>
>> -----Original Message-----
>> From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
>> Sent: Thursday, May 13, 1999 11:46 AM
>> To: [EMAIL PROTECTED]
>> 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".
