在我的應用程序中,我可以按名稱註冊不同的數據源。這些數據源每個都有幾個所需的屬性,以及一組其他依賴項,但其他依賴項都是相同的,因此需要一些不同的標準實現。Ninject提供程序:什麼是解決依賴關係的正確方法
爲了在請求時構建每個數據源的實例,我創建了一個綁定到Provider<T>
的實例,該實例使用訪問該數據源所需的信息進行初始化。提供者看起來像下面:
public class StandardListProvider<T> : Provider<IListExecutor<T>>
where T : new()
{
public string Name { get; set; }
public string ListMethod { get; set; }
public StandardListProvider(string name, string listMethod)
{
Name = name;
ListMethod = listMethod;
}
protected override IListExecutor<T> CreateInstance(IContext context)
{
var connector = (IInternalConnector)context.Kernel.GetService(typeof(IInternalConnector));
return new StandardListExecutor<T>(connector, Name)
{
ListMethodName = ListMethod
};
}
}
的問題是解決StandardListExecutor<T>
像IInternalConnector
的依賴。很顯然,我可以手動構建它們,或者按照我的示例(並由Ninject Providers -> Get another dependency inside the provider建議)從context.Kernel
請求它們,但是這會導致無目標信息的請求,如果要爲依賴關係執行上下文綁定的StandardListExecutor
。
我試過玩context.Request.CreateChild(...)
,但是這似乎需要反思每個激活來創建一個ParameterTarget
。在Ninject文檔中似乎也沒有關於這方面的很多信息。
我的問題是:在現有綁定的激活過程中,解決/請求依賴關係或其他類似服務的正確方法是什麼?
編輯
本身經由Ninject.Mvc進行連接到System.Web.Mvc控制器活化方法制得的請求。
你的問題缺少的是如何提供的對象實際上「請求」。因此,我並不真的看到這裏需要提供商。你爲什麼不創建一個綁定呢?您可以將構造函數參數添加到綁定中。更好的做法可能是爲每個執行者創建一個「FooParameters」或「FooSettings」類型。 – BatteryBackupUnit
Hi @BatteryBackupUnit - 實際請求通過Ninject.Mvc連接進入控制器激活過程。創建一個綁定來處理所有這些誠實的想法並沒有發生在我身上,也沒有爲每種不同類型的執行者創建一個設置對象。我真的希望獲得儘可能多的激活邏輯,以便綁定本身由「IMissingBindingResolver」創建。在任何情況下,我的問題都是關於如何最好地創建自定義的Provider,因爲這個問題在幾個不同的項目中已經出現了。 – s3raph86