Ninject 2.0 - 綁定到多次使用相同接口的對象？

Question

考慮以下幾點：

public Something(IInterface concreteObjectOne, IInterface concreteObjectTwo) 
    { 
     this.concreteObjectOne = concreteObjectOne; 
     this.concreteObjectTwo = concreteObjectTwo; 
    } 

如何設置設置此類型與Ninject結合起來？我試着用谷歌搜索這個詞，但是因爲我不確定這個名字叫什麼，我也不知道，我也不能在維基上找到任何關於這個的東西。

編輯：

我相信這就是所謂的以公約爲基礎的結合，如所描述here。但是，此文檔適用於版本1.0，而2.0不具有Only方法。我希望這可以在沒有屬性的情況下實現 - 使用名稱約定或類似的東西。

Answer 1

除了使用「唯一」方法，本文還通過爲注入對象指定不同的屬性來提出另一種解決方案。

例子：

public class ObjectOneAttribute : Attribute 
{ 

} 
public class ObjectTwoAttribute : Attribute 
{ 

} 

然後

public Something([ObjectOneAttribute] IInterface concreteObjectOne, [ObjectTwoAttribute] IInterface concreteObjectTwo) 
    { 
     this.concreteObjectOne = concreteObjectOne; 
     this.concreteObjectTwo = concreteObjectTwo; 
    } 

而當你想界面到正確的具體對象綁定，使用 「WhereTargetHas」 的方法：

Bind<IInterface>().To<YourConcreteTypeOne>().WhereTargetHas<ObjectOneAttribute>(); 
Bind<IInterface>().To<YourConcreteTypeTwo>().WhereTargetHas<ObjectTwoAttribute>(); 

更新：解不使用屬性：
使用方法 「當」：

Bind<IInterface>().To<YourConcreteTypeOne>().When(r => r.Target.Name == "concreteObjectOne"); 
Bind<IInterface>().To<YourConcreteTypeTwo>().When(r => r.Target.Name == "concreteObjectTwo") 

;

Answer 2

如果我可能被允許提供一些通用的，而不是Ninject特定的指導，我建議你稍微重新考慮你的設計。目前的構造函數是含糊，因爲它沒有提供關於IInterface的哪個實現在哪裏的指導 - 我意識到這僅僅是您真實API的模型，而真正的API可能會爲開發人員提供更多幫助恰當命名參數的形式，像DI容器這樣的機器無法推斷正確的用法。

許多DI容器提供了一些方法來解決這種模糊問題，例如通過提供可用於將名稱（元數據）與每個依賴項相關聯的屬性。 AFAIR，Ninject有Inject屬性...

然而，考慮幾個選擇：

第一個選擇是封裝在兩個類似的接口實例在參數對象，像這樣：

public interface IParameterObject 
{ 
    IInterface ObjectOne { get; } 

    IInterface ObjectTwo { get; } 
} 

您現在可以更改構造函數以獲取IParameterObject的實例，而不是使用兩個接口實例本身。

public Something(IParameterObject po) 
{ 
    this.concreteObjectOne = po.ObjectOne; 
    this.concreteObjectTwo = po.ObjectTwo; 
} 

這意味着您可以將IParameterObject的配置推送到Composition Root。

另一種方法去思考是，是否是有意義的考慮兩個實例只是一個特殊情況更普遍的設計，採用實例的任何數量的的的情況。這可能並非總是如此，但如果是這樣，你可以改變構造這樣：

public Something(IEnumerable<IInterface> objects) 

我個人喜歡的任何的上述建議在使用特定Ninject功能什麼，因爲它迫使我通常使API更明確，從而更易於讀取和維護。