我已經使用統一爲我的最後一個項目，並普遍高興。但基準測試讓我想到我可能會使用Simple Injector進行下一個項目。爲什麼Simple Injector不像Unity這樣的IContainer抽象？
但是，簡單噴油器似乎沒有它的Container類的接口。這意味着，無論何時我想在方法中使用容器，我都不能嘲笑容器進行單元測試。
我很困惑如何真正基於接口功能的工具本身並不會爲容器創建接口。我知道依賴注入的經典方法在啓動時不需要容器。 （其餘的部分使用構造函數注入。）但是我發現，當橡膠撞擊道路時並不總是如此。有時你只需要容器就可以在代碼中進行「解析」。
如果我使用Simple Injector，那麼該代碼似乎越來越難以進行單元測試。
我對不對？或者我錯過了什麼？
簡單的噴油器不包含抽象，因爲那將是無用的：
這將是無用的，簡單的注射器來定義它， 因爲你的代碼將在這種情況下，仍取決於庫（因爲Simple Injector定義了抽象），並且這導致供應商鎖定，該簡單注射器爲tries to prevent。
除了應用程序的Composition Root之外，您編寫的任何代碼不應取決於容器，也不應取決於容器的抽象。兩者都是Service Locator anti-pattern的實現。
單元測試時，不應該使用DI庫。在進行單元測試時，您應該手動在被測試的類中注入所有假或模擬對象。使用容器只會使事情複雜化。也許你正在使用一個容器，因爲手動創建這些類對你來說太麻煩了。這可能表明您的代碼存在問題（您可能違反了Single Responsibility Principle）或您的測試（您可能缺少factory method to create the class under test）。
您可能會將容器用於您的集成測試，但您首先應該沒有那麼多的集成測試。重點應放在單元測試上，應用依賴注入模式時應該很容易。最重要的是，與集成測試中隱藏容器相比，取決於非常寬的庫定義的接口，有更好的方法。
你自己定義這樣的接口（加上一個適配器）是微不足道的，證明它沒有在庫中。作爲應用程序開發人員的職責是按照Dependency Inversion Principle的規定爲您的應用程序定義正確的抽象。傾向於這樣做的圖書館和框架在大多數情況下都會失敗，無法提供適用於每個人的抽象概念。
庫本身並不使用該抽象，根據Framework Design Guidelines，庫應該不會爲您定義這種抽象。如前所述，Simple Injector無論如何都會得到錯誤的抽象。
最後但並非最不重要的一點，Simple Injector容器實際上實現了System.IServiceProvider，它在mscorlib.dll中定義並可用於檢索服務對象。
我不想在我的測試中使用容器。我想單元測試一個使用容器的方法。在這種情況下，我不能嘲笑容器不使用完整的SimpleInjector邏輯。 – Vaccano 2013-04-26 16:21:39
好的，我們將嘗試這種與Unity不同的方式。對於Unity，我們嘲笑IContainer返回模擬。這樣，我們的單元測試不會使用（測試）Unity。我們將嘗試SimpleInjector。我們將容器的測試版本傳遞給被測對象的構造函數（在需要時）。該測試版本將設置爲返回模擬。所以實質上，我們將在我們的測試中使用SimpleInjector東西來返回模擬，但是在生產中它將返回在啓動時設置的對象。我覺得我必須嘗試一下，因爲SimpleInjector只是非常快速！ – Vaccano 2013-04-26 16:42:33
但是爲什麼這個類會依賴於容器？具有（足夠）邏輯測試的類不應直接依賴於他的容器。只有基礎結構組件（它們是組合根的一部分）應該對容器或容器的抽象有依賴關係。您顯然無法測試您的系統，因爲您違反了此規則。 – Steven 2013-04-26 21:51:13
我覺得這裏給出的答案是完全在接受該服務定位是一個反模式，這反過來我不相信是全球公認的真正成立。請參閱Windows Workflow Foundation的擴展支持。
反模式鏈接（及其兩個更新）也可能很弱...最新的更新聲稱違反了封裝（「減輕了你必須理解你的每一段代碼的每個實現細節的負擔代碼庫「），然後同時宣稱先驗知識的依賴關係在聲明方面與通過單元測試發現它們有所不同。無論哪種方式，你都需要知道該給它什麼。總而言之，如果你想遵循定位器模式，可以利用它的IServiceProvider，或者簡化你的容器羣（單身），併爲它創建一個靜態包裝器。
爲什麼不使用抽象工廠而不是注入容器？ – onof 2013-05-07 06:16:37