Some more information (this also serves as a summary/distillation of the
original post):
I tried to make sure that the reasons for using SB Facade to EB in the past
-- encapsulate interaction of multiple EBs, avoid long transactions, reduce
network overhead of client interacting with multiple entity beans -- were
not an issue here because the example uses a single entity bean. FOR THIS
EXAMPLE, whether the client interacts with a Session Bean facade or the
entity bean, it doesn't matter in terms of encapsulation, avoidance of long
transactions and reduction of network overhead because the client would be
interacting with a SINGLE entity or session bean.
So ... I'm trying to see if separation of responsibilites is a good enough
reason to provide a SB facade IN THIS CASE. With separation of
responsibilities, we get easier maintenance and the use of
object-to-relational tools for generation of the persistence code. But we
also get another bean. Are these enough of an advantage to use a SB Facade?
Again, the example case is not as straightforward because of the following:
1. The 'freshness mechanism' is closely associated with the object's
persistence.
2. The client is making a request to a single bean, whether it's an entity
bean or a session bean. It will not be making multiple requests that are
all part of the same transaction nor is it making requests to multiple beans
(this means that, again, we don't need to create a facade to reduce network
overhead or encapsulate interaction or avoid long transactions).
Thanks again,
Bill
===========================================================================
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".
