业务代表和服务定位器的区别是什么?同时负责封装查找和创建机制。如果业务代表使用服务定位器来隐藏查找和创建机制，那么业务代表的专用意义是什么呢?服务定位器不能代替业务代表吗?
我不知道你是否已经看过了，但这是一个好的开始。
使用业务代表封装对业务服务的访问。业务代表隐藏了业务服务的实现细节，比如查找和访问机制。
Service Locator封装了搜索和/或获取基于通用注册中心的特定服务的位置、限制和必需字段所需的逻辑。业务代表封装了一组相关的服务，并以一种内聚的方式公开它们，以防止服务客户不得不搜索和访问与某个功能相关的所有服务。
另外，您避免了客户必须实际了解服务定位器和它应该使用的服务，而将其留给特定的业务代表。客户端只需要该委托来执行一组相关任务或依赖于各种服务的任务。
业务代表实际上并没有封装一组服务定位器。它在服务定位器上提供了一个抽象层，以提供一个内聚的服务子集。通常只有一个服务定位器实例，多个实例需要一个额外的映射，您应该知道哪个服务定位器提供服务X，将其视为您需要一个服务定位器。
举例说明。
考虑用户帐户管理。UserBusinessDelegate查找注册服务来注册用户，然后查找认证服务来允许登录。客户端只需要一个业务代表来访问这些服务，他不需要知道两个服务的id。
这些服务id封装在UserBusinessDelegate中，避免了声明id和到处使用服务定位器的需要。想想看，如果一个服务id改变了会发生什么?
在这种情况下，负责的业务代表被更新，避免对客户端的直接影响。
这些模式有一个共同点，因此这个问题很有意义。
它们都帮助客户端使用服务。
假设我们有公开为EJB、WS或POJO的服务。客户端可以直接使用服务定位器访问这些服务。(允许在此组件中封装一些复杂性)这改进了客户端的代码，但客户端仍然负责知道服务是如何公开的。(他必须为特定的服务选择正确的服务定位器)。
此解决方案的一个缺点是客户端将与服务高度耦合。例如:a)如果明天作为EJB公开的服务更改为WS，我们必须更改客户端代码(使用另一个服务定位器)。b)如果我们想使用模拟服务测试客户端代码，我们必须更改代码。
业务代表的出现是为了降低耦合级别。现在客户端与业务代表交互(在更高的抽象级别)，因此他不需要知道任何关于服务实现细节的其他信息。
当然，由于业务代表与服务定位器交互，服务定位器仍然是有用的。
以最简单的方式，我喜欢将业务代表视为接口(改进解耦)，将服务定位器视为助手(封装与基础设施相关的行为)