以下面的文章为例：
我认为与传统的软编码方法相比，IOC方法没有什么好处。有人能告诉我我错过了什么吗？
由于
答案 0 :(得分：6)
文章本身几乎可以回答你的问题：
在生产过程中，依赖注入接管并自动为我提供
AppConfigSettings实例。为了测试，我生成了一个模拟IApplicationSettings。
一般来说，设计模式，实践和方法（IoC不是一个模式）试图帮助您至少一件事：最小化coupling和最大化cohesion。当您直接使用ConfigurationManager以及所有（Convert.ToBoolean等）时，您将：
ConfigurationManager（不利于测试和重用）.config文件之外，没有其他方法可以配置您的类;对于测试和重用也不好）当然，仅使用IoC 来读取配置设置是一种矫枉过正，但这篇文章肯定只涉及更大图片的一小部分。
答案 1 :(得分：0)
对于IoC的特定应用，这意味着您无需知道使用设置的所有字符串键，只需在您阅读它们的位置。
这也意味着可以为Foo类提供来自配置文件以外的其他位置的应用程序设置。这对于单元测试或Foo的一次性实例非常有用，这些实例需要除配置文件中定义的设置以外的设置。
一个很好的问题可能是：Foo应该知道如何阅读配置设置和使用它们吗？
答案 2 :(得分：0)
在那篇特别的文章中，Patrick解除了Foo类对配置文件的直接依赖性，它的结构等。通过实现这些设置的接口，然后将它们从外部传递到Foo类，Foo得到了它所需要的东西，按预期运行但不再仅依赖于配置文件。 Foo并不关心设置的来源。
这些概念称为解耦和依赖注入，有助于创建更易于管理的内容，并且根据Patrick的示例，可以使用更多可测试的代码。
答案 3 :(得分：0)
IoC为您提供真正独立的可重用组件，而不仅仅是可配置的单片系统。单片系统难以维护，因为一切都是相互依赖的。组件化系统更易于推理，测试和更改，因为您可以单独使用每个部件。
控制反转意味着各个组件只能通过抽象相互访问，并且没有说明它们如何连接在一起。如果您阅读UML spec（上层结构规范第8章）中的组件，那么很明显IoC和“组件”的概念必须始终齐头并进：
基于组件的一个重要方面 开发是以前的重用 构造组件。一个组件 永远可以被认为是自治的 系统或子系统内的单元。它 有一个或多个提供和/或 必要的接口（可能 通过端口暴露）及其内部 隐藏，除了之外无法访问 由其接口提供。 虽然它可能依赖于其他 接口方面的元素 是必需的，一个组件是 封装及其依赖性 设计得可以治疗 尽可能独立。作为一个 结果，组件和子系统都可以 灵活地重复使用并替换为 连接（“接线”）它们在一起 通过他们提供和要求 接口。自治的方面 并且重用也扩展到组件 部署时间。这些文物 实现组件旨在 能够被部署和 为了独立重新部署 实例来更新现有系统。