IOC对软编码有什么好处？

Question

以下面的文章为例：

http://weblogs.asp.net/psteele/archive/2009/11/23/use-dependency-injection-to-simplify-application-settings.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+dotnetmvp+%28Patrick+Steele%27s+.NET+Blog%29

我认为与传统的软编码方法相比，IOC方法没有什么好处。有人能告诉我我错过了什么吗？

由于

Answer 1

文章本身几乎可以回答你的问题：

  

在生产过程中，依赖注入接管并自动为我提供AppConfigSettings实例。为了测试，我生成了一个模拟IApplicationSettings。

一般来说，设计模式，实践和方法（IoC不是一个模式）试图帮助您至少一件事：最小化coupling和最大化cohesion。当您直接使用ConfigurationManager以及所有（Convert.ToBoolean等）时，您将：

• 将代码耦合到ConfigurationManager（不利于测试和重用）
• 将您的代码耦合到配置文件本身（除了通过.config文件之外，没有其他方法可以配置您的类;对于测试和重用也不好）
• 混合职责（阅读和解析配置设置;违反SRP）

当然，仅使用IoC 来读取配置设置是一种矫枉过正，但这篇文章肯定只涉及更大图片的一小部分。

Answer 2

对于IoC的特定应用，这意味着您无需知道使用设置的所有字符串键，只需在您阅读它们的位置。

这也意味着可以为Foo类提供来自配置文件以外的其他位置的应用程序设置。这对于单元测试或Foo的一次性实例非常有用，这些实例需要除配置文件中定义的设置以外的设置。

一个很好的问题可能是：Foo应该知道如何阅读配置设置和使用它们吗？

Answer 3

在那篇特别的文章中，Patrick解除了Foo类对配置文件的直接依赖性，它的结构等。通过实现这些设置的接口，然后将它们从外部传递到Foo类，Foo得到了它所需要的东西，按预期运行但不再仅依赖于配置文件。 Foo并不关心设置的来源。

这些概念称为解耦和依赖注入，有助于创建更易于管理的内容，并且根据Patrick的示例，可以使用更多可测试的代码。

Answer 4

IoC为您提供真正独立的可重用组件，而不仅仅是可配置的单片系统。单片系统难以维护，因为一切都是相互依赖的。组件化系统更易于推理，测试和更改，因为您可以单独使用每个部件。

控制反转意味着各个组件只能通过抽象相互访问，并且没有说明它们如何连接在一起。如果您阅读UML spec（上层结构规范第8章）中的组件，那么很明显IoC和“组件”的概念必须始终齐头并进：

  

基于组件的一个重要方面   开发是以前的重用   构造组件。一个组件   永远可以被认为是自治的   系统或子系统内的单元。它   有一个或多个提供和/或   必要的接口（可能   通过端口暴露）及其内部   隐藏，除了之外无法访问   由其接口提供。   虽然它可能依赖于其他   接口方面的元素   是必需的，一个组件是   封装及其依赖性   设计得可以治疗   尽可能独立。作为一个   结果，组件和子系统都可以   灵活地重复使用并替换为   连接（“接线”）它们在一起   通过他们提供和要求   接口。自治的方面   并且重用也扩展到组件   部署时间。这些文物   实现组件旨在   能够被部署和   为了独立重新部署   实例来更新现有系统。