手動解決Unity依賴關係

是否可以在方法內部使用Resolve <>在構造函數或類的屬性中注入依賴項？手動解決Unity依賴關係

public void Foo() 
{ 
    if (...) 
     var context = Unity.Resolve<Context>(); 
}

的想法是，使用統一管理作爲一般的DI使用創建的對象的生存條件的依賴性的決心。 DI在Web Api項目中設置，所以MVC DependencyResolver.Current不起作用。

來源

2015-08-18 Max Bündchen

雖然這被認爲是由一些壞的模式，可以實現簡單的靜態Service Locator模式的這樣一種形式：

public static class Unity 
{ 
    private static IUnityContainer _container; 

    public static void SetAppContainer(IUnityContainer container) 
    { 
     _container = container; 
    } 

    public static T Resolve<T>() 
    { 
     return _container.Resolve<T>(); 
    } 
}

來源

2015-08-18 21:25:06

我想知道Web Api是否具有像MVC DependencyResolver.Current（與您的代碼相同）等內置功能。 –

是的。我們之前使用過它。 http://www.asp.net/web-api/overview/advanced/dependency-injection –

我也在使用這個解決方案，但它需要將容器對象存儲到所有應用程序範圍，因此您的解決方案是必需的內置Unity。當config.DependencyInjection設置爲UnityResolver時，我無法訪問該屬性來獲取當前的DI並使用它。 –

這不是一個好主意。應用程序中應該知道容器的唯一部分是組合根。這是服務定位器的一個示例，它是一種反模式，因爲依賴關係沒有明確聲明。

這聽起來像你想引入一個工廠類型，可以通過構造函數注入注入。

來源

2015-08-18 21:22:51 devdigital

是的，這是一個反模式，但我有一個情況，這是令人滿意的表現。 –

你能解釋一下嗎？ – devdigital

一種情況是使用令牌進行身份驗證：在我的應用程序中99％的時間令牌沒有數據庫訪問，因此我不需要一個新的上下文（它當然是出貨，但規模可能會成爲問題）。在正常情況下，應始終使用構造函數注入。 –

手動解決Unity依賴關係

回答

相關問題