什么时候使用IoC合适？

Question

我了解什么是IoC容器，并且一直在阅读结构图。这项技术似乎很容易使用。我的问题是，使用IoC容器时适当的粒度级别是多少？

我看到以下应用可能水平IOC：

1. 打破所有对象之间的每一个相关性 - 当然矫枉过正。
2. 所有主要对象（如域对象，支持类和子系统内的组件）之间的中断依赖关系。
3. 使用IoC与Facade结合使用公共接口包装子系统（如日志记录），然后中断对该接口的依赖关系。

我知道这个问题的答案是“它取决于”，但是从你的经验来看，那么答案依赖于什么？项目规模是否是一个因素？

此外，IoC不适合使用？

Answer 1

这个想法并不是要破坏域对象之间的依赖关系，而是为了保护你的域与外界无关。您的域对象应该是关于您正在解决的任何业务问题，而不是关于数据库，日志记录，缓存，http上下文，休息服务等等......

本文讨论将职责移出对象并移入IoC容器。

http://www.agileatwork.com/captcha-and-inversion-of-control/

Answer 2

我认为当你知道你将编写大量的单元测试时，使用它是有意义的，因为它使这些测试的构建更容易。此外，它允许您（通过外部配置）在运行时更改对象的行为。

在较小的项目或不需要大规模解耦的项目上使用IoC是没有意义的。

Answer 3

我想说，当你知道你需要一个灵活的应用程序时最有意义，因为需求会经常变化，或者你将与一个开发团队一起工作在一个大型系统上。它有助于在团队中工作，因为您可以完成工作，并让IoC处理您的依赖关系。

Answer 4

国际奥委会的一个场景就是当一个具体的实施决定在开发团队中受到质疑时。 IOC提供了以最小的摩擦交换实施的灵活性。这比任何事情都更具战术性。

Answer 5

好了，国际奥委会并没有做出很大的意义，如果你正在编写，将不会有多种类型实现的非常具体的成分......

例如;假设你正在为你的公司编写一个文档阅读器，并且你知道这样一个事实：阅读器背后的商业规则是它永远不会阅读任何其他文档类型，然后是MS Word文档。在这种情况下，你的单元测试并不需要依赖注入的松耦合，因为你正在测试的组件将永远不依赖于除了MS Word文档以外的其他任何东西。使用IOC容器来解析阅读器类型可能只是矫枉过正。