什麼時候使用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容器來解析閱讀器類型可能只是矯枉過正。