全局对抗依赖注入有人说用依赖注入比较好。这是为什么？我认为最好有一些全局的、易于访问的类而不是庞大的构造函数。它会以任何方式影响应用程序的速度吗？两者的混合可能是最好的。主要优点是解耦，这将有助于单元测试。这种情况完全取决于你如何编写这些“易于访问的类”。这个想法是这样的。通过仅依赖契约（接口），类与实现（类）依赖关系分离。在您的实际环境中，您可能永远不会提供新的实现类，但在您的测试环境中，您很可能会提供（无论是手工制作的存根，还是来自模拟框架的模拟类）。应用程序的速度需要分析，但使用DI框架而不是直接与您知道的单例对话可能会有一些开销。重要的问题是：这是一个问题吗？只有性能预期和分析可以告诉您。根据我的经验，好处远远超过可忽略不计的性能损失。您可以将静态类和方法用作全局变量。它们没有性能影响。但是，静态类不适合可测试性。静态方法的缺点是什么？此外，一旦您的代码与静态类(Globals)紧密耦合，您就无法在未来用替代实现替换它们。因此，除非在非常简单的情况下使用，否则Globals可能不是好的设计。请注意，静态类和方法是编译时绑定，而DI是运行时绑定。帮助您保持类的松散耦合。使用“全局”和DI之间存在巨大差异。首先，通常不会引导路径，因为您可能会单步执行单例和服务定位器。今天，两者都被认为是一种反模式。原因是我们应该设计可测试的代码，当我们需要更改维护代码库或满足新需求时，这会给我们带来很大的好处。如果代码是分离的，那么可测试性很容易实现。您猜测全局行为对解耦没有帮助，因此例如，如果您有加入静态单例的代码，要测试此类代码，您需要单例本身，并且您不能模拟它，这很糟糕，因为您不能随心所欲地对您的系统施加压力。服务定位器乍一看似乎更好：如果你需要测试，你可以一步一步地模拟服务定位器，但你必须：构造函数中的DI是解耦代码的好方法，因为你非常清楚object需要表现content，mocks、stubs等可以一眼判断。请注意，如果您确保没有将DI内核作为代码的依赖项，DI将起作用并为您提供帮助：这将以反模式转换DI（您解耦代码，但将其绑定到容器），所以记得学习并真正实现基于模式的根模式，这会让你更好地编写更好的可测试代码。我认为关于这个主题的最上面的帖子对DI以及如何以正确的方式使用它有一个很好的总结：依赖注入（DI）“友好”库如果你想更深入地研究这个主题，我可以推荐MarkSeeman的“.NET中的依赖注入》一书。以上就是《C#学习教程：全球对抗依赖注入》分享的全部内容。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
