C# 您何时会使用 Common Service Locator？

When would you use the Common Service Locator?

提问by ajma

I've been looking at the Common Service Locatoras a way of abstracting my IoC container but I've been noticing that some people are strongly against this type of this.

我一直将Common Service Locator视为抽象 IoC 容器的一种方式，但我注意到有些人强烈反对这种类型。

Do people recommend never using it? Always using it? or sometimes using it? If sometimes, then in what situations would you use it and what situations would you not use it.

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

采纳答案by Ian Ringrose

Imagine you are writing library code to be used by 3rd party developers. Your code needs to be able to create service objects that these developers provide. However you don't know which IoC container each of your callers will be using.

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

The Common Service Locator lets you cope with the above without forcing a given IoC on your users.

Common Service Locator 可让您处理上述问题，而无需将给定的 IoC 强加给您的用户。

Within your library itself you may wish to register your own classes in the IoC, now it gets a lot harder as you need to choose a IoC for your own use that will not get in the way of your callers.

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

回答by Grant Palin

I've done some reading on the service locator concept lately. It is a way of helping to reduce coupling, but requires code coupling to the locator - not the container backing the locator, but the locator itself. It is a tradeoff, but can be beneficial in the right situation.

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

One situation where it can be helpful is when you have code that does not make use of DI, such as legacy code - I am in this boat now. Pulling in required objects via SL, rather than directly creating them, allows the addition of some abstraction. I see it as an intermediate step between SL and DI/IoC.

它可以提供帮助的一种情况是，当您拥有不使用 DI 的代码时，例如遗留代码 - 我现在就在这条船上。通过 SL 引入所需的对象，而不是直接创建它们，允许添加一些抽象。我将其视为 SL 和 DI/IoC 之间的中间步骤。

回答by Steven

I noticed that one of the arguments against using the CSL is a false one, because developers think this library is only capable of doing the Service Locator pattern. This however isn't the case, because it is easy to use it with the Dependency Injection pattern as well.

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

However, the CSL library was specially designed for framework designers who need to allows users to register dependencies. Because the library will be calling the CSL directly, from the framework's perspective we're talking about the SL pattern, hence its name.

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

As a framework designer however, taking a dependency on the CSL shouldn't be taking lightly. For usability of your framework it is normally much better to have your own DI mechanism. A very common mechanism is to set up dependencies in the configuration file. This pattern is used throughout the whole .NET framework. Almost every dependency can be replaced for another. The .NET provider pattern is built on top of this.

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

When you, as a framework designer, take a dependency on the CSL, it will be harder for users to use your application. Users will have to configure an IoC container and hook it up to the CSL. However, it is not possible for the framework to validate the configuration as can be done while using the .NET configuration system, which as all kind of validation support in it.

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

回答by Abhijeet Patel

If you have library code that is in need of services and this code could be hosted in the context of a larger framework/runtime then the framework / runtime would need to provide a mechanism where you can run some custom code on startup wherein you can initialize your container and register dependencies. A good example of where CSL can be problematic is when using it in the context of MSCRM. You can have custom business logic executed by registering plugins which the MSCRM framework executes on certain events. The problem you run into is where do you run the registration logic since there is no "startup" event that you can subscribe to for setting up your DI container. Even if you could somehow setup your DI you would need to put the CSL and the DI libraries in the GAC since that is the only way to call out to 3rd party code from a plugin (one more item to add to your deployment checklist). In scenarios such as this you are better off having your dependencies as constructor parameters that the calling code can initialize as it sees fit( via either constructor injection or manually "newing" up the appropriate interface implementation).

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