问题
What is the difference between Business Delegate and Service Locator.Do both responsible for encapsulating lookup and creation mechanism.If Business Delegate uses Service Locator for hiding lookup and creation mechanism then what is Business Delegate exclusively meant for, can't Service Locator replace Business Delegate.
回答1:
I don't know if you already checked this out, but it's a good start.
Use a Business Delegate to encapsulate access to a business service. The Business Delegate hides the implementation details of the business service, such as lookup and access mechanisms.
A Service Locator encapsulates the logic required to search and/or obtain the location, restrictions and required fields for a certain service based on a general registry. A Business Delegate encapsulates a group of related services and exposes them in a cohesive way to prevent a service customer from having to search and access all the services related to a certain functionality.
Plus, you prevent the customer from having to actually know the Service Locator and the services it should consume, leaving that to a particular Business Delegate. A client only needs that delegate to perform a group of related tasks or a task that relies in various services.
Example
A Business Delegate doesn't actually encapsulate a group of Service Locators. It provides an abstraction layer over a Service Locator to provide a cohesive subset of services. Usually there's only one instance of a Service Locator, multiple instances require an additional mapping where you should know WHICH Service Locator provides Service X, think of it as if you would need a Service Locator Locator.
An example should help clarify things.
Think about user account management. The UserBusinessDelegate looksup the registration service to register an user and then looksup the authentication service to allow a log in. The client only needs one Business Delegate to access those services and he doesn't need to know the id of both services.
Those service ids are encapsulated in the UserBusinessDelegate avoiding the need of declaring the ids and using a Service Locator everywhere. Think about this, what would happen if one service id changes?.
In such cases the Business Delegate in charge is updated, avoiding a direct impact for the client.
回答2:
These patterns have a common point therefore this question have a lot of sense.
Both of them help a client to consume a service.
Let suppose that we have services exposed as EJB, WS or POJO. The client may access such services using the Service Locator directly. (allowing some complexity to be encapsulated inside this component) This improve the cliente's side code but the client is still responsible for knowing how the service is exposed. (He has to select the right Service Locator for the specific service).
One disadvantage of this solution is that the client would be highly coupled with the service. For example: a) if tomorrow the service that is exposed as an EJB changes to WS we have to change the client's code (use another Service Locator). b) If we want to test the client's code using a mock service, we have to change code.
Business Delegate come to scene to decrease the level of coupling. Now the client interacts (in a higher abstraction level) with the Business Delegate, therefore he doesn't need to know anything else about service implementation details.
Of course the Service Locator is still useful due to the Business Delegate interacts with him.
At the simplest way, I like to think aboutn Business Delegate as an interface (improves decoupling) and a Service Locator as a helper (encapsulates infrastructure related behavior)
来源：https://stackoverflow.com/questions/14405919/business-delegate-vs-service-locator