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

我看不出有來自國際奧委會的做法，而不是傳統的編碼軟辦法什麼好處。有人能告訴我我錯過了什麼嗎？

感謝

Answer 1

物品本身幾乎回答你的問題：

在生產過程中，依賴注入接管並自動給我我AppConfigSettings實例。爲了測試，我生成了一個模擬IApplicationSettings。

一般來說，設計模式，實踐和方法（國際奧委會沒有太大的模式）儘量幫你至少還有一兩件事：儘量減少coupling和maxmize cohesion。如果您是直接使用ConfigurationManager和所有（Convert.ToBoolean等），你是：

• 耦合代碼到ConfigurationManager（壞測試和重用）
• 耦合代碼到配置文件本身（沒有其他的方法來配置不是通過.config文件等類;壞的測試和重用以及）
• 混合責任（讀取和解析配置設置;違反SRP）

授予，使用IoC 只有閱讀配置設置是一個矯枉過正，但肯定這篇文章只涉及一個更大的圖片的一小部分。

Answer 2

對於IoC的特定應用，這意味着您無需知道使用設置的任何地方的字符串鍵，就是您讀取它們的位置。

這也意味着Foo類可以給出來自配置文件以外的地方的應用程序設置。這對於單元測試非常有用，或者對於需要設置不同於配置文件中定義的設置的Foo的一次性實例。

一個很好的問題要問可能是：應該Foo知道如何讀的配置設置和使用它們？

Answer 3

在那篇特別的文章中，Patrick解耦了Foo類對配置文件的直接依賴，它是結構等。通過實現這些設置的接口，然後將它們從外部傳遞給Foo類，Foo得到了它所需的，按原樣運行，但不再僅依賴於配置文件。 Foo不關心設置的來源。

這些概念被稱爲解耦和依賴注入，並幫助創建更多的可管理的，並且按照帕特里克的例子，更可測試的代碼。

Answer 4

IoC爲您提供真正獨立的可重用組件，而不僅僅是一個可配置的單片系統。單片系統難以維護，因爲一切都是相互依存的。組件化系統更容易推理，測試和更改，因爲您可以單獨使用每個部分。

控制反轉意味着個別組件只能通過抽象訪問彼此，並且在如何將它們連接在一起時沒有發言權。如果你讀了有關在UML spec（上層建築規範第8章）成分，那麼很明顯，國際奧委會和「部件」的概念必須始終如影隨形：

基於組件的 發展的一個重要方面是以前的 構造組件的重用。組件 始終可以被認爲是系統或子系統內的自治的單元。其 具有一個或多個提供的和/或 所需的接口（可能通過端口暴露 ），並且其內部 隱藏且不可訪問，而不是由其接口提供的 。儘管它可能依賴於其他需要接口的元件，但是封裝了一個組件 並且其依賴關係是 ，其被設計成使得它可以儘可能獨立地被視爲 。作爲 的結果，組件和子系統可以靈活地重複使用，並由 通過它們提供的和需要的 接口將它們連接（「接線」）在一起 代替。自治 和重用的方面也延伸到部署時間的組件 。 實現組件的工件旨在爲能夠被部署的 和獨立重新部署的 ，用於更新現有系統的 實例。