驗證我瞭解IoC，Ioc容器，DI和服務定位器之間的區別

Question

閱讀關於3個慣用語之間區別的許多帖子。但變得更加困惑，然後我碰到這篇文章： http://martinfowler.com/articles/injection.html

只是想看看我是否得到這個權利。如果我錯了，請糾正我。 請通知我修正和補充：

IOC-是脫鉤它使用一個服務的實現應用程序的概念。該應用程序包含Iservice的參考資料，並且不需要實例化具體服務。

有至少兩個才達到這樣的方式：

1. DI - 混凝土業務注入的構造函數PARAM /扔一個setter /扔接口注入（什麼後者意味着什麼呢？）

2. ServiceLocator - 是一個知道應用程序可能需要的所有具體服務的組件。該應用程序明確要求定位器的具體服務。

* IoC容器實際上是控件的工廠（「提供者」）。

我對文章中的「何時偏好（1）或（2）」部分有些困惑。 有人可以從他自己的經驗中看出一個外行人的話嗎？

「服務定位器由於其更直接的行爲而具有輕微的優勢，但如果要構建在多個應用程序中使用的類，則依賴注入是更好的選擇。」 - >定位器如何更直接？因爲它明確使用方法調用？有多個應用程序時使用DI有什麼好處？

Answer 1

IoC是將應用程序與其使用的服務的實現分離的概念。

確實，IoC與解耦接口與實現脫鉤，但我認爲它是一個更一般的原則。 This SO answer給出了這個概念的很好的解釋。

有才達到這樣的至少兩種方式：
1）DI
2）的ServiceLocator

我不會說的服務定位器模式是反向控制的一個例子。恰恰相反 - 當你使用服務定位器時，你正以主動的方式獲得所需的依賴關係，沒有人爲你做這件事（與容器爲你處理依賴關係的DI相反，你只需要給它一個這樣做的可能性 - setter，構造函數參數或實現注入接口的方法）。

定位器如何更直接？因爲它明確使用方法調用？

我認爲Martin Fowler指的是IoC的總體思路，如果您從未見過以前使用過的IoC/DI概念，則可能會使代碼更難理解。另一方面，使用服務定位器獲取一些依賴關係的代碼在第一次遇到時可能會更容易掌握。

當有多個應用程序時使用DI有什麼好處？

當你創建一個被認爲是可重用的組件，DI的優點是它不會使你的組件依賴於任何東西比原來依賴其他人（在MF的例子中，MovieLister只取決於使用DI時的MovieFinder接口）。 另外，其他人使用你的組件非常容易 - 只需使用你提供的DI的方式傳遞依賴關係。

使用服務定位器時，還需要添加對服務定位器本身接口的依賴性。使用定位器的隔離界面，這可能不成問題。但它也可能難以爲組件的用戶，以滿足您的組件的依賴，爲MF寫道：

的差別來，如果李斯特是我提供給應用程序，其他人是組件寫作。在這種情況下，我對客戶要使用的服務定位器的API知之甚少。每個客戶可能都有自己的不兼容的服務定位器。