Business Delegate / Session Facade interaction questions
I understand the concept and the benefits of a business delegate "front-ending" a session facade. I am hoping that someone can answer the following questions:
Is it acceptable if a business delegate were to front-end more than one session facade in order to create a more unified service. For example is it ok to create one business delegate that provides Account Inquiry and Maintenance functionality and behind the scenes it talks to an AccounInquiry Session Facade and AccountMaintenance Session Facade?
We are looking at a designing a Account Inquiry business delegate. It will return an AccountProfile business object. A behaviour of the AccountProfile object will be update capability (i.e. update account status, modify balance, etc.). Considering that the business object is a "business tier" component, is it ok fif it were to talk directly to an Account Update Session Facade or instead should it use a business delegate which in turn will call the session facade?
Definitely. You can have multiple business delegates for a given facade (to give different API "views" to the same underlying service, say one is read-only and another allows full privileges) as well as a single business delegate for multiple session facades (to act as a mini-controller for atomic services that will be chained together). Both are acceptable. In fact, if you keep a strict ratio of 1:1, you are liminiting the design possibilities inherent in tiering an application.
- Saish
"My karma ran over your dogma." - Anon
Saish at 2007-7-1 13:25:49 >
> I understand the concept and the benefits of a
> business delegate "front-ending" a session facade. I
> am hoping that someone can answer the following
> questions:
>
> Is it acceptable if a business delegate were to
> front-end more than one session facade in order to
> create a more unified service. For example is it ok to
> create one business delegate that provides Account
> Inquiry and Maintenance functionality and behind the
> scenes it talks to an AccounInquiry Session Facade and
> AccountMaintenance Session Facade?
This is a feasible solution. As long as you have 1:2 ratio or a ratio which is very less, it is fine. But one of the intents for having this pattern is also to make the client's life easier. If the client who's using your delegate is someone else, sitting else where, he/she would be wondering about the reason for a single class like AccountInquiryMaintenanceDelegate providing two different functionalities. So, this has to be kept in mind before coming up with a single class.
> We are looking at a designing a Account Inquiry
> business delegate. It will return an AccountProfile
> business object. A behaviour of the AccountProfile
> object will be update capability (i.e. update account
> status, modify balance, etc.). Considering that the
> business object is a "business tier" component, is it
> ok fif "it"
what does "it" mean here? Did you mean the 'AccountProfile' bussiness object? or the AccountInquiry business delegate?
> were to talk directly to an Account Update
> Session Facade or instead should it use a business
> delegate which in turn will call the session facade?
>
HTH,
Kalyan
