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 if 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? Thanks
Conversely, you could ask yourself "Why wouldn't it be OK?". An intermediary such as the business delegate is used to shield one class from changes in another class. This enhances maintainability by confining ripple effects of changes to one general area of the application. So you have to ask yourself at least two things: 1. What is the likelihood of the interfaces changing? 2. If the interface changes, how much and how far do those changes reverberate through the application if I use one approach vs. another approach? When it comes to interaction across tiers though, I think it's better to have as few duplicate points of contact as possible.
Mark, My opinion: I don't see why not. Imagine having one big huge interface listing all the possible methods that your service layer supports. From a maintenance point of view, you have a central point of view to add/update business methods. Or you could have something like this: