我认为，了解两者之间的区别以及DI容器为什么比服务定位器好得多的最简单方法是首先考虑一下为什么要进行依赖关系反转。
我们进行依赖倒置，以便每个类明确声明其操作所依赖的内容。我们这样做是因为这会产生我们可以实现的最宽松的耦合。耦合越松，测试和重构就越容易（由于代码更简洁，将来通常需要最少的重构）。
让我们看下面的类：
public class MySpecialStringWriter
{
private readonly IOutputProvider outputProvider;
public MySpecialFormatter(IOutputProvider outputProvider)
{
this.outputProvider = outputProvider;
}
public void OutputString(string source)
{
this.outputProvider.Output("This is the string that was passed: " + source);
}
}
在此类中，我们明确指出需要一个IOutputProvider并不需要其他任何东西来使该类正常工作。这是完全可测试的，并且依赖于单个接口。我可以将此类移动到应用程序中的任何地方，包括一个不同的项目，它所需要的只是对IOutputProvider接口的访问。如果其他开发人员想要向此类添加新的东西（需要第二个依赖项），则必须明确说明构造函数中需要的东西。
使用服务定位器查看同一类：
public class MySpecialStringWriter
{
private readonly ServiceLocator serviceLocator;
public MySpecialFormatter(ServiceLocator serviceLocator)
{
this.serviceLocator = serviceLocator;
}
public void OutputString(string source)
{
this.serviceLocator.OutputProvider.Output("This is the string that was passed: " + source);
}
}
现在，我已将服务定位器添加为依赖项。以下是显而易见的问题：
- 这样做的第一个问题是要花费更多的代码才能达到相同的结果。更多代码是不好的。它不是更多的代码，但还有更多。
- 第二个问题是我的依赖关系不再明确。我仍然需要在课堂上注入一些东西。除了现在，我要的东西不是很明确。它隐藏在我要求的东西的属性中。现在，如果我想将类移动到其他程序集，则需要同时访问ServiceLocator和IOutputProvider。
- 第三个问题是，其他开发人员可能会增加一个附加的依赖关系，而他们甚至在向类添加代码时都没有意识到自己正在接受它。
- 最后，此代码更难测试（即使ServiceLocator是一个接口），因为我们必须模拟ServiceLocator和IOutputProvider而不是IOutputProvider
那么，为什么不将服务定位器设为静态类呢？让我们来看看：
public class MySpecialStringWriter
{
public void OutputString(string source)
{
ServiceLocator.OutputProvider.Output("This is the string that was passed: " + source);
}
}
这要简单得多，对吗？
错误。
假设IOutputProvider是由运行时间很长的Web服务实现的，该服务将字符串写入世界各地的15个不同数据库中，并且需要很长时间才能完成。
让我们尝试测试该类。我们需要测试的IOutputProvider的不同实现。我们如何编写测试？
为此，我们需要在静态ServiceLocator类中进行一些精美的配置，以在测试调用IOutputProvider时使用不同的IOutputProvider实现。即使写那句话也很痛苦。实施它将是一种折磨，这将是维护的噩梦。我们永远不需要修改专门用于测试的类，尤其是如果该类不是我们实际尝试测试的类时。
因此，现在剩下的是：a）一个测试，该测试导致不相关的ServiceLocator类中的代码更改过大；或b）完全没有测试。而且，您还剩下一个不太灵活的解决方案。
因此，服务定位器类具有被注入到构造函数。这意味着我们剩下前面提到的特定问题。服务定位器需要更多的代码，告诉其他开发人员它不需要的东西，鼓励其他开发人员编写更糟糕的代码，并给我们带来更少的灵活性。
简单地说，服务定位符会增加应用程序中的耦合，并鼓励其他开发人员编写高度耦合的代码。
