2

Business Delegate和Service Locator有什么区别。Do都负责封装查找和创建机制。如果Business Delegate使用Service Locator来隐藏查找和创建机制，那么Business Delegate是什么意思，Service Locator不能代替Business Delegate .

4

2 回答 2

3

我不知道你是否已经检查过了，但这是一个好的开始。

使用业务委托来封装对业务服务的访问。Business Delegate 隐藏了业务服务的实现细节，例如查找和访问机制。

服务定位器封装了基于通用注册表搜索和/或获取特定服务的位置、限制和必填字段所需的逻辑。业务代表封装了一组相关服务，并以一种内聚的方式公开它们，以防止服务客户不得不搜索和访问与特定功能相关的所有服务。

此外，您还可以防止客户必须真正了解服务定位器及其应使用的服务，而将其留给特定的业务代表。客户端只需要该委托来执行一组相关任务或依赖于各种服务的任务。

例子

业务代表实际上并不封装一组服务定位器。它在服务定位器之上提供了一个抽象层，以提供一个内聚的服务子集。通常只有一个 Service Locator 实例，多个实例需要一个额外的映射，您应该知道哪个 Service Locator 提供了 Service X，把它想象成您需要一个Service Locator Locator。

一个例子应该有助于澄清事情。

考虑用户帐户管理。查找注册服务以注册用户，然后UserBusinessDelegate查找身份验证服务以允许登录。客户端只需要一个业务代表即可访问这些服务，并且他不需要知道这两个服务的 ID。

这些服务 id 被封装在UserBusinessDelegate避免声明 id 和在任何地方使用服务定位器的需要中。想一想，如果一个服务 id 发生变化会发生什么？

在这种情况下，负责的业务代表会更新，避免对客户产生直接影响。

于 2013-01-18T19:25:53.180 回答
0

这些模式有一个共同点，因此这个问题很有意义。

它们都帮助客户使用服务。

假设我们将服务公开为 EJB、WS 或 POJO。客户端可以直接使用服务定位器访问此类服务。（允许在此组件中封装一些复杂性）这改进了客户端的代码，但客户端仍然负责了解服务的公开方式。（他必须为特定服务选择正确的服务定位器）。

此解决方案的一个缺点是客户端将与服务高度耦合。例如： a) 如果明天作为 EJB 公开的服务更改为 WS，我们必须更改客户端的代码（使用另一个服务定位器）。b) 如果我们想使用模拟服务测试客户端的代码，我们必须更改代码。

业务代表上门降低耦合度。现在客户端与业务代表进行交互（在更高的抽象级别），因此他不需要了解有关服务实现细节的任何其他信息。

当然，由于业务代表与他交互，服务定位器仍然有用。

以最简单的方式，我喜欢将 Business Delegate 视为接口（改进解耦），将 Service Locator 视为助手（封装与基础设施相关的行为）

于 2013-04-22T14:37:15.590 回答