您什么时候使用公共服务定位器？

Question

我一直在寻找Common Service Locator作为抽象我的IoC容器的方法，但我注意到有些人强烈反对这种类型。

人们建议永远不要使用它吗？ 一直在使用它？ 或者有时使用它？ 如果有时，那么在什么情况下你会使用它以及你不会使用它的情况。

Answer 1

想象一下，您正在编写供第三方开发人员使用的库代码。 您的代码需要能够创建这些开发人员提供的服务对象。 但是，您不知道每个呼叫者将使用哪个IoC容器。

通用服务定位器可让您在不强制用户使用特定IoC的情况下处理上述问题。

在您的库中，您可能希望在IoC中注册自己的类，现在它变得更加困难，因为您需要选择一个不会妨碍您的呼叫者使用的IoC。

Answer 2

我注意到反对使用CSL的一个论点是假的，因为开发人员认为这个库只能执行Service Locator模式。 然而事实并非如此，因为它也很容易与依赖注入模式一起使用。

但是，CSL库是专为需要允许用户注册依赖项的框架设计者而设计的。 因为库将直接调用CSL，从框架的角度来看，我们正在谈论SL模式，因此它的名称。

然而，作为框架设计者，依赖于CSL不应该掉以轻心。 为了您的框架的可用性，拥有自己的DI机制通常要好得多。 一种非常常见的机制是在配置文件中设置依赖项。 这种模式在整个.NET框架中使用。 几乎每个依赖都可以替换为另一个。 .NET提供程序模式建立在此基础之上。

当您作为框架设计者依赖CSL时，用户将更难以使用您的应用程序。 用户必须配置IoC容器并将其连接到CSL。 但是，框架不可能在使用.NET配置系统时验证配置，因为.NET配置系统中包含所有类型的验证支持。

Answer 3

我最近对服务定位器概念做了一些阅读。 这是一种帮助减少耦合的方法，但需要代码耦合到定位器 - 而不是支持定位器的容器，而是定位器本身。 这是一种权衡，但在适当的情况下可能是有益的。

它可能有用的一种情况是当你有不使用DI的代码时，例如遗留代码 - 我现在就在这艘船上。 通过SL拉入所需的对象，而不是直接创建它们，允许添加一些抽象。 我认为它是SL和DI / IoC之间的中间步骤。

Answer 4

如果您有需要服务的库代码，并且此代码可以托管在更大的框架/运行时的上下文中，那么框架/运行时需要提供一种机制，您可以在启动时运行一些自定义代码，您可以在其中初始化您的容器和注册依赖项。 CSL可能存在问题的一个很好的例子是在MSCRM的上下文中使用它。 您可以通过注册MSCRM框架在某些事件上执行的插件来执行自定义业务逻辑。 您遇到的问题是在哪里运行注册逻辑，因为没有“启动”事件可以订阅以设置您的DI容器。 即使您可以以某种方式设置您的DI，您也需要将CSL和DI库放在GAC中，因为这是从插件中调出第三方代码的唯一方法（还有一个项目要添加到您的部署清单中）。 在诸如此类的场景中，最好将依赖关系作为构造函数参数，调用代码可以在其认为合适时初始化（通过构造函数注入或手动“新建”适当的接口实现）。