什么时候使用IoC合适？

Question

我了解IoC容器是什么，并且已经在Structure Map上阅读了。该技术似乎很容易使用。我的问题是，使用IoC容器的适当粒度级别是多少？

我看到IoC的以下可能应用级别：

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

我知道这个问题的答案是“它取决于”，但根据您的经验，那么答案取决于什么？项目规模是一个因素吗？

此外，IoC在哪里使用都没有意义？

Answer 1

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

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

Answer 2

嗯，如果你编写一个不具备多种类型实现的非常具体的组件，那么IOC没有多大意义......

例如;假设您正在为您的公司编写文档阅读器，并且您知道读者背后的业务规则是它永远不会读取任何其他文档类型，而是MS Word文档。在这种情况下，您的单元测试实际上并不需要依赖注入的松散耦合，因为您正在测试的组件永远不会依赖于MS Word文档之外的任何其他内容。使用IOC容器来解析阅读器类型可能有点过分。

Answer 3

我们的想法不是打破域对象之间的依赖关系，而是要保护您的域名不受外界影响。您的域对象应该是您要解决的任何业务问题，而不是数据库，日志记录，缓存，http上下文，休息服务等......

本文讨论将责任从对象转移到IoC容器中。

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

Answer 4

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

Answer 5

IOC的一个场景是在开发团队中对特定的实施决策提出质疑。 IOC提供了以最小摩擦交换实现的灵活性。这比任何事情都更具战术意义。