1

IoC和自動裝配的困擾是IoC對創建對象的可用性。IoC - 在組件內創建的對象的自動裝配

可以說我有一個靜態的Utils類,用於整個系統。當我決定使用IoC和DI時,我很容易將Utils更改爲非靜態,並讓所有組件都接收其實例。

但是,只有在引導過程中創建的組件,在運行時創建的對象或作爲用戶操作響應的對象以及使用Utils,自動佈線不起作用,自動佈線才能正常工作。相反,我必須手動將Utils的實例傳遞給在運行時創建的每個對象的每個實例。

我能看到的唯一方法就是使用傳遞IoC容器的反模式,這當然不是我想要做的。

還有別的辦法嗎?還是我不得不手動將Utils手動傳遞給每個實例和類?

注:這不是一個設計問題。當然,我可以通過各種方式儘量減少這種隱喻性實用程序的使用,但在許多情況下,這是不可避免的。

回答

3

圍繞它的唯一途徑,我可以使用的 的反模式通過周圍的IoC容器,我當然不希望 確實看到。

答案很簡單:使用抽象工廠。

通過在應用程序中定義工廠接口並在Composition Root(您的引導程序代碼)中定義工廠實現,您可以防止使用Service Locator反模式。該工廠實現可以持有對容器的引用並將其稱爲請求實例。由於該實現是引導邏輯的一部分,因此該實現是基礎架構組件,並且您是not using it as a service locator

實施例:

public interface IUnitOfWorkFactory 
{ 
    IUnitOfWork CreateNew(); 
} 

實現在組合物根:

internal class SimpleInjectorUnitOfWorkFactory 
    : IUnitOfWorkFactory 
{ 
    private readonly SimpleInjector.Container container; 

    public SimpleInjectorUnitOfWorkFactory(Container container) 
    { 
     this.container = container; 
    } 

    public IUnitOfWork CreateNew() 
    { 
     return this.container.GetInstance<IUnitOfWork>(); 
    } 
} 
+0

感謝。這是一些思想材料。我猜[自動工廠](http://blogs.msdn.com/b/stuartleeks/archive/2010/04/28/unity-2-0-automatic-builders.aspx)也是一個選項呢? – VitalyB

+0

當然,但既然你沒有給你的答案貼上標籤,我給了一個普遍的答案。順便說一句,我是一個保持簡單的東西,不使用任何DI框架特定的東西的粉絲,除非它真的讓事情變得更簡單(而且代碼本身並不簡單)。 – Steven

+0

好點。我確實使用Unity,所以我標記了這樣的問題。你不使用DI框架?手動操作DI可能是一件很麻煩的事情,但是......當你有幾個組件時,每個組件都需要不同的構造器參數(而且我甚至沒有提到DI框架的終生支持)......但是,再次,我只是一個新手與DI,所以我的意見可能會改變。謝謝! – VitalyB