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

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

公共服务定位器允许您处理上述问题,而无需对用户强制指定IOC。

在你的图书馆里,你可能希望在国际奥委会注册你自己的课程,现在这变得更加困难了,因为你需要选择一个国际奥委会供你自己使用,而这不会妨碍你的呼叫者。

我注意到反对使用CSL的其中一个论点是错误的,因为开发人员认为这个库只能执行服务定位器模式。然而,情况并非如此,因为它也很容易与依赖注入模式一起使用。

然而,CSL库是专门为框架设计人员设计的,他们需要允许用户注册依赖项。因为库将直接调用CSL,从框架的角度来看,我们讨论的是SL模式,因此它的名称。

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

作为一个框架设计者,当你依赖CSL时,用户将很难使用你的应用程序。用户必须配置一个IOC容器并将其连接到CSL。但是,框架不可能像使用.NET配置系统时那样验证配置,因为它支持所有类型的验证。

我最近读了一些关于服务定位器的概念。这是一种帮助减少耦合的方法,但需要代码耦合到定位器-不是支持定位器的容器,而是定位器本身。这是一种权衡,但在正确的情况下是有益的。

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

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