关闭。这个问题是opinion-based .它目前不接受答案。
想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.
2年前关闭。
Improve this question
我看到很多文章都在说 IoC 和 DI 有多棒，却没有说为什么它不那么棒，因为它会使代码变得更复杂。我还看到 IoC 不应该是代码的核心部分，而应该更多地用于库和插件。文章通常很少提及这两种模式如何使代码变得更复杂，但没有太多关于细节的介绍。那是我的问题——你不应该在哪里使用这些模式？
这是一个很好的线程:What is Inversion of Control? .如果你再往下看，有一篇关于拼写检查器的帖子和另一篇关于 IoC 如果它只是一个拼写检查器的话，它可能不是很好用的帖子。作为一般准则，是否应该不使用 IoC，因为我曾经只有一个具体的接口(interface)类？意思是，我有 IMyClass。然后只有实现 IMyClass 的具体 MyClassA。为什么我想要 IoC？
如果我有 MyClassA、MyClassB 和 MyClassC，它们每个都实现了 IMyClass，那么这些可能是 IoC 的好候选人，对吗？
从同一个线程，有谁知道这篇文章的意思:
最佳答案
关于您关于只有一个接口(interface)实现的问题。当您使用 IoC 时，使用接口(interface)仍然很有用。使用这些接口(interface)的模拟来创建真正的单元测试(不依赖于接口(interface)实现是否正常工作)会容易得多。使用 IoC 的核心是让代码更容易测试。所以，如果你不想测试，或者已经有了更好的测试计划，就不要使用 IoC。
恕我直言， DI 和 IoC 复杂性的增加是通过更容易测试和更少耦合的代码来支付的。 更容易隔离问题并进行 future 更改。你也可以更好地控制它的行为。
我可以看到何时不使用 IoC 容器(因为它会导致配置开销)。这将发生在小型项目上，您可以手动完成，而不是使用容器。但是我看不出使用 DI 有多少损失，除非你不打算测试你的代码......
关于design-patterns - 什么时候不使用 IoC 和 DI？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1362962/