2011-09-20 66 views
7

是否有可能通過Unity或其他類型的IoC庫中插入依賴項這樣的列表?Unity .NET:依賴關係列表

public class Crawler 
{ 
    public Crawler(IEnumerable<IParser> parsers) 
    { 
     // init here... 
    } 
} 

這樣我可以在我的容器中註冊多個IParser,然後解決它們。

可能嗎?謝謝

+2

[解決IEnumerable 與Unity](http://stackoverflow.com/questions/1961549/resolving-ienumerablet-with-unity) –

回答

0

不是我說這是錯誤的,但它似乎是你試圖解決一個插件模型,你可以輕鬆地使用MEF管理而不是。提示將被繼承從接口導出,然後在需要解析器時執行ImportMany。

-1

是的,你可以..你可以看看依賴注入器。我是Autofac項目的忠實粉絲。

另一種選擇是Ninject

9

這是可能的,但需要應用一些解決方法。首先,您需要在Unity容器中註冊每個IParser。其次,您需要在容器中註冊從IParser []IEnumerable <IParser>的映射。否則,容器不能將解析器注入到構造函數中。這是我以前做過的事情。

IUnityContainer container = new UnityContainer(); 

container.RegisterType<IParser, SuperParser>("SuperParser"); 
container.RegisterType<IParser, DefaultParser>("DefaultParser"); 
container.RegisterType<IParser, BasicParser>("BasicParser"); 
container.RegisterType<IEnumerable<IParser>, IParser[]>(); 
container.RegisterType<Crawler>(); 

Crawler crawler = container.Resolve<Crawler>(); 

我已經拋棄了這個解決方案,通過引入一個工廠,封裝統一構建所需的類型。這就是我將如何做你的情況。

public interface IParserFactory{ 
    IEnumerable<IParser> BuildParsers(); 
} 

public class UnityParserFactory : IParserFactory { 
    private IUnityContainer _container; 

    public UnityParserFactory(IUnityContainer container){ 
    _container = container; 
    } 

    public IEnumerable<IParser> BuildParsers() { 
    return _container.ResolveAll<IParser>(); 
    } 
} 

public class Crawler { 
    public Crawler(IParserFactory parserFactory) { 
    // init here... 
    } 
} 

有了這個,你可以按如下所示註冊類型:

IUnityContainer container = new UnityContainer(); 

container.RegisterType<IParser, SuperParser>(); 
container.RegisterType<IParser, DefaultParser>(); 
container.RegisterType<IParser, BasicParser>(); 
container.RegisterType<IParserFactory, UnityParserFactory>(); 

Crawler crawler = container.Resolve<Crawler>(); 
0

由於事實上,我不知道,不支持這一任何容器。

但是,作爲一般性建議,如果可以的話,您應該防止將服務列表注入消費者,方法是將該列表包裝在composite中,然後將該組合注入消費者。如果不在組合中包裝列表,將會使應用程序變得雜亂無章,或者需要做些什麼來處理這些依賴關係列表。雖然這看起來不錯,但這些依賴關係的消費者不應該在意。但更糟糕的是,當我們想改變處理服務列表的方式時,我們將不得不完成整個應用程序,這違反了DRY原則。

當消費者(在您的案例中Crawler)是Composition Root而不是應用程序本身的一部分時,此建議不適用。此外,當應用程序只有一個使用此依賴項的消費者時,它可能不是那麼重要。