Java 业务代理与服务定位器

Business Delegate和Service Locator之间的区别是什么。两者都负责封装查找和创建机制。如果Business Delegate使用Service Locator隐藏查找和创建机制，那么Business Delegate专用于什么，无法用服务定位器替换业务代理。

我不知道您是否已经退出，但这是一个良好的开端

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

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

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

---

示例

业务委托实际上并不封装一组服务定位器。它在服务定位器上提供了一个抽象层，以提供服务的内聚子集。通常一个服务定位器只有一个实例，多个实例需要一个额外的映射，您应该知道哪个服务定位器提供服务X，将其视为您需要一个服务定位器

举个例子应该有助于澄清问题

考虑一下用户帐户管理。

UserBusinessDelegate

查找注册服务以注册用户，然后查找身份验证服务以允许登录。客户端只需要一个业务代理就可以访问这些服务，而不需要知道这两个服务的id

这些服务ID封装在

UserBusinessDelegate

中，避免了声明ID和到处使用服务定位器的需要。想想看，如果一个服务id发生变化会发生什么

---

在这种情况下，负责的业务代表会被更新，从而避免对客户造成直接影响。

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

它们都可以帮助客户机使用服务

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

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

业务代表来到现场以降低耦合级别。 现在，客户机与业务委托进行交互（在更高的抽象级别上），因此他不需要知道关于服务实现细节的任何其他信息

当然，由于业务代理与服务定位器交互，因此服务定位器仍然很有用

---

以最简单的方式，我喜欢将业务委托视为接口（改进解耦），将服务定位器视为助手（封装与基础架构相关的行为）

好吧……只有您知道您希望将解耦的概念发展到什么程度。从概念上讲，这两个词的意思是做不同的事情……正如下面甘布的回答所暗示的那样。但是，可以在同一个组件中查找EJB引用并公开业务方法。对于具有较少业务方法和较少查找的较小应用程序，请使用一个组件。对于较大的应用程序，请使用不同的组件SSO Kaushik，如果我们说业务代理和服务定位器在较小的应用程序中都可以做相同的工作，并且其中一个可以替换另一个，这是正确的吗，请您提供一个场景。正如您所说，服务定位器封装了搜索和/或获取位置所需的逻辑（即查找和访问机制），Business Delegate封装了一组相关服务并公开了它们，那么，我们可以说Business Delegate封装了一组服务定位器，用于相关服务的查找和访问机制吗？我已经更新了我的答案，我希望这个示例有助于澄清问题。正如其他人所说，业务代理在某些复杂环境中很有用。小型应用程序很适合使用服务定位器。谢谢你，甘伯，如果我们为用户帐户管理创建一个服务定位器，那么服务定位器的角色是什么呢。Business Delegate-->Service Locator-->Registration Service流程是：Business Delegate公开该函数，当客户端请求该函数时，该委托会询问服务定位器在何处找到该函数，服务定位器提供信息，该委托使用该服务，最后将过程结果返回给用户。所以基本上你是对的。