Business Delegate VS Session Facade
George Fung
Ranch Hand
Posts: 98
posted 10 years ago
After I read the book Core J2EE Patterns, the structure and aim of 2 patterns are very simliar. The aim is to hide the implementation details of business layer, reduces coupling and provide uniform interface. I have the following problemes:
1. Can anyone tell me which suitation we should use BD or SF?
2. Any difference between them?
3. How they cooperate with each other?
Thanks a lot....
1. Can anyone tell me which suitation we should use BD or SF?
2. Any difference between them?
3. How they cooperate with each other?
Thanks a lot....
SCJP, SCJD, SCWCD, SCBCD, SCEA, SCJP6
To be obtained: SCEA 5
Aleena Rehman
Ranch Hand
Posts: 66
posted 10 years ago
DEFINITION - A Facade substitutes the interfaces of a set of classes with the interface of a single class. Facade hides implementation classes behind one interface. [Design Patterns by Gamma et al]
DEFINITION - The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture. [J2EE Design Patterns by * et al]
So Using a facade to encapsulate calls to your business model is called the Business Delegate pattern.
The session facade pattern is used have one clear interface into your application. Behind that you can hide how it is actually implemented, session beans here and there, the odd ejb, dao too etc. You can then change about the implementation without changing your clients view of the application.
The business delegate is used to hide the fact that you have a session bean there. It can cache the EJB look ups saving you time, and be used to convert nasty EJB exceptions into something more user friendly. When you change your application model from session beans to the next fade you wont have to change your clients there.
DEFINITION - The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture. [J2EE Design Patterns by * et al]
So Using a facade to encapsulate calls to your business model is called the Business Delegate pattern.
The session facade pattern is used have one clear interface into your application. Behind that you can hide how it is actually implemented, session beans here and there, the odd ejb, dao too etc. You can then change about the implementation without changing your clients view of the application.
The business delegate is used to hide the fact that you have a session bean there. It can cache the EJB look ups saving you time, and be used to convert nasty EJB exceptions into something more user friendly. When you change your application model from session beans to the next fade you wont have to change your clients there.
Aleena Rehman<br />SCJP, SCBCD 95%, SCWCD 85%, IBM-OOAD 84%, SCEA-I 91%
George Fung
Ranch Hand
Posts: 98
Lars Behnke
Ranch Hand
Posts: 76
posted 10 years ago
George,
You could do so. However, both patterns address different concerns. BD (on client side) hides Remote-Exceptions and other server stuff from clients. SF (on server side) hides complexity of business classes from clients. So I would keep them separated.
Imagine you want to change from EJB to web services in order to open your application for non-Java clients. That's where an server side SF becomes important. These non-Java clients would need to implement own business delegates.
Regards,
Lars
[ November 22, 2006: Message edited by: Lars Behnke ]
But I think BD can act as SF in the same class. It provides simliar functionality. What do you think?
You could do so. However, both patterns address different concerns. BD (on client side) hides Remote-Exceptions and other server stuff from clients. SF (on server side) hides complexity of business classes from clients. So I would keep them separated.
Imagine you want to change from EJB to web services in order to open your application for non-Java clients. That's where an server side SF becomes important. These non-Java clients would need to implement own business delegates.
Regards,
Lars
[ November 22, 2006: Message edited by: Lars Behnke ]
