This is a great discussion. I hope others are benefiting from it as much as
I am!
One of the major merits of OOD has been knowing where to find business logic
and some specific behavior like retrieval. That further allows reuse and
better encapsulation.
IMHO it's always better to strive and keep as much behavior with entity
beans as possible and sensible. As systems grow there are several session
beans using the same entity beans and there are better chances of re-use and
consistency.
It makes sense to me that the retrieval be done on the entity beans.( I am
thrilled that we hopefully will have custom methods on the home which
basically represents the class/static behavior of the class).
The session beans can actually wrap the call on the entity bean and then
return a collection of non remote data objects as the client requires.
This essentially breaks up the logic into session and entity bean behavior,
put's the presentation logic on the sesion bean and locator/finder methods
on the entity bean. BTW , I feel that even when you have retrievals spanning
multiple entities, the focus is usually on one entity. Say orders and their
customer - I think it makes sense to have the retrieval method on order.
Further I feel this makes sense irrespective of whether the retrieval is a
custom finder method returning orders or a sql doing a join of orders and
customers. Agreed a sql call looks uglier on the entity bean but if that's
the way you want it, I see merit in having it on the entity bean, returning
a ResultSet used by several different sesion beans.
Now talking about whether to use a JDBC call VS a custom finder for orders
and then a call to load a customer for each order.
Option 1. A custom finder method on Order would return an enumeration of
orders and the session bean then iterates through the orders, gets the
customer - creates a data object with all required info and then returns a
collection of data objects to the client. This is all happening on the
server side though there could by a huge number of database calls depending
on how many customer entities are currently cached. But there are no remote
calls from client to the server when the client displays the list.
Option 2. Use a jdbc call where the sql is doing a join between the order
and the customer.The session bean then iterates through the resultSet,
creates a data object with all required info and then returns a collection
of data objects to the client.
I know that option 1 would be slower but cleaner but have most of you found
the difference significant enough to use option 2 ?
p.s - Even though we can't have custom methods on home right now, we've
added such methods as static methods on the beans themselves and added
methods to our session beans to wrap these. I know there is restriction on
having non final static variables but I don't think there are restrictions
on having static methods on a bean. We've done this for the same reasons -
we want entity class behavior on the entity and not on session beans. Anyone
know if we are violating the EJB specs ?
Sachin Aggarwal
Noosh Inc.
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Chip Wilson
Sent: Thursday, May 13, 1999 10:33 AM
To: [EMAIL PROTECTED]
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".
