Business Delegate和Service Locator之间有什么区别。两者都负责封装查找和创建机制。如果业务代表使用Service Locator来隐藏查找和创建机制，那么Business Delegate专门用于什么，可以＆＃t; t服务定位器替换业务代表。
答案 0 :(得分：3)
我不知道你是否已checked this，但这是一个好的开始。
使用业务代表封装对业务服务的访问权限。业务代表隐藏业务服务的实现细节，例如查找和访问机制。
服务定位器封装了基于通用注册表搜索和/或获取特定服务的位置，限制和必填字段所需的逻辑。业务代表封装了一组相关服务，并以一种有凝聚力的方式公开它们，以防止服务客户必须搜索和访问与某个功能相关的所有服务。
另外，您可以阻止客户真正了解服务定位器及其应该使用的服务，并将其留给特定的业务代表。客户端只需要该委托执行一组相关任务或依赖于各种服务的任务。
示例
业务代表实际上并未封装一组服务定位器。它在服务定位器上提供了一个抽象层，以提供一个有凝聚力的服务子集。通常只有一个服务定位器实例，多个实例需要一个额外的映射，您应该知道哪个服务定位器提供服务X，将其视为您需要服务定位器定位器。
一个例子应该有助于澄清事情。
考虑用户帐户管理。 UserBusinessDelegate查找注册服务以注册用户，然后查找身份验证服务以允许登录。客户端只需要一个业务代表来访问这些服务，并且他不需要知道这两个服务的ID
这些服务ID封装在UserBusinessDelegate中，无需在任何地方声明ID并使用服务定位器。想一想，如果一个服务ID改变会发生什么？。
在这种情况下，负责的业务代表会更新，避免对客户产生直接影响。
答案 1 :(得分：0)
这些模式有一个共同点，因此这个问题很有意义。
它们都可以帮助客户使用服务。
假设我们将服务公开为EJB，WS或POJO。 客户端可以直接使用服务定位器访问此类服务。 （允许将一些复杂性封装在此组件中） 这改善了客户端代码，但客户仍然负责了解服务的公开方式。 （他必须为特定服务选择合适的服务定位器。）
此解决方案的一个缺点是客户端将与服务高度耦合。 例如： a）如果明天将作为EJB公开的服务更改为WS，我们必须更改客户端的代码（使用另一个服务定位器）。 b）如果我们想使用模拟服务测试客户端的代码，我们必须更改代码。
业务代表来到现场以降低耦合水平。 现在，客户端与业务代表进行交互（在更高的抽象级别中），因此他不需要了解有关服务实现细节的任何其他信息。
当然，由于业务代表与他进行交互，服务定位器仍然有用。
最简单的方法是，我喜欢将Business Delegate视为一个接口（改进解耦）和一个Service Locator作为帮助（封装与基础架构相关的行为）