全球对抗依赖注入

Question

有些人说使用依赖注入会更好。那是为什么？

我认为最好是拥有一些全局的，易于访问的类，而不是庞大的构造函数。

它是否以任何方式影响申请速度？

这两者的混合可能是最好的。

Answer 1

主要优势是解耦，这将有助于单元测试。这种情况完全取决于您如何编写这些“易于访问的类”。

这个想法是这样的。通过仅依赖于契约（class），类与实现（interface）依赖关系分离。在您的实时环境中，您可能永远不会提供新的实现类，但在您的测试环境中，您很可能（无论是手工制作的存根，还是来自模拟框架的模拟类）。

应用程序速度需要分析，但是使用DI框架可能会产生一些开销，而不是直接与你所知道的单例交谈。重要的问题是：这是一个问题吗？只有性能期望和分析可以告诉你。根据我的经验，其好处远大于可忽略不计的性能损失。

Answer 2

您可能会使用static类和方法作为Globals。它们没有任何性能影响。但是，静态类不适合可测试性。

What are the downsides to static methods?

此外，一旦您的代码与静态类（Globals）紧密耦合，您将来无法用替代实现替换它们。因此，除非在非常简单的情况下使用，否则Globals可能不是很好的设计。

请注意，静态类和方法是编译时绑定，其中 DI是运行时绑定。 帮助您保持课堂松散耦合。

Answer 3

使用“全局”和DI之间存在巨大差异。首先，路径通常不会被引导，因为您可能会逐步完成singleton和service locator。今天两者都被认为是一种反模式。原因是我们应该设计可测试代码，当我们需要更改维护代码库或满足新需求时，这给我们带来了很大的好处。如果代码分离，则易于实现可测试性。你猜测全局行为对解耦没有帮助，所以例如如果你有代码加入一个静态单例，要测试这样的代码你需要单例本身，你就不能嘲笑它，这很糟糕因为你不能随心所欲地强调你的系统。服务定位器乍一看似乎更好：如果需要测试，你可以逐步模拟服务定位器，但你必须：

• 事先知道被测系统会向定位器询问哪些服务
• 始终创建“递归模拟”，因为您可能也会模拟返回的服务。

构造函数上的DI是代码解耦的好方法，因为您非常清楚地说明对象需要运行的内容，并且您可以一目了然地判断模拟，存根等等。请注意DI将起作用并帮助您，如果您确保不将DI内核作为代码依赖于代码：这将在反模式中转换DI（您将代码分离，但是将其绑定到容器），所以记得学习并真正实现c omposition root pattern，这真的会让你写出更好，更可测试的代码。

Answer 4

我认为这个主题的最高职位有一个非常好的DI总结以及如何以正确的方式使用它：Dependency Inject (DI) "friendly" library

如果您想深入了解该主题，我可以推荐Mark Seeman撰写的“.NET中的依赖注入”一书。