This week's book giveaways are in the Refactoring and Agile forums.
We're giving away four copies each of Re-engineering Legacy Software and Docker in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Business delegate design pattern

 
geet kaur
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Ranchers!!
I was just going through the design patterns.viz the "business delegate".according to what i understood about it is:



A business delegate hides the complexity of the remote services etc. from the controller.It interacts with the Service Locator for the Remote
Object,Which is a stub,and then calls the methods on this stub.I hope i got it right??

But somwhere i read that it acts as a stub,it implements the remote interface.What exactly is true regarding the business delegate??
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The primary purpose of the pattern is to reduce the degree of coupling between one or more client objects and one or more objects that provide business functionality, i.e. business objects. The pattern can be implemented on the Presentation-tier or Business-tier.

Aside, "Business Delegate" is the name of a design pattern so both words in the name should be capitalized. Also, the word "I" is always capitalized, not only when it is the first word of a sentence. For example, "When I went to the store I purchased a container of milk."

 
Vladimir Ozerov
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do not agree with your explanation.
1) Business delegate can only be placed on presentation tier. If we place this code on the business logic tier, than we can name it Facade, Gateway, Adapter and so on (depending on implementation details), but not Business Delegate.
2) The main purpose of this pattern is to decouple the client from stub implementation details and its underlying technology. In this case the client can get rid of handling EJB2.0-specific excpetions, RMI exceptions and so on.
I.e. instead of having the call:
Client -> Client stub (where client stub is tightly coupled to some tehcnology, e.g. EJB, RMI, SOAP, REST, JMX, CORBA, etc.)
... we would have
Client -> Business Delegate -> Client stub
... and the delegate will completely hide the stub from us.
 
Vladimir Ozerov
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A little correction to my previous post:
1) Business delegate can only be placed on presentation tierclient's side.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There can be client objects that reside on the Business tier. These would be business objects that request services from another business objects. The J2EE Business Delegate pattern applied here as well.

Aside, the term "client object" can refer to more than one concept. Here I'm not referring to "client side" or anything related to the "user" of an application.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic