創建依賴注入綁定的兩種常見機制（例如通過IOC容器）來自XML配置或命令代碼塊。在這些情況下，鍵值對是明確的（即鍵=請求類型，值=返回類型）。（自動）依賴注入綁定機制
儘管如此，還有第三種「啓發式」方法，其中僅嚮應用程序/ IOC容器提供[IMyClass]鍵，然後容器反映一組應用程序程序集依賴關係以查找所有名稱匹配的具體類[MyClass] 。換句話說，「返回類型」值是被發現的而不是被聲明的。
我想知道的是兩方面的：
這就是所謂的基於約定的配置或自動註冊並由這些支持。NET DI容器：
用於DI容器最常見的配置機制
第四，但少見，方法是使用屬性。 Managed Extensibility Framework是這種方法中最突出的例子，這在Java中更爲常見。
我通常做了你所描述的配置中的一個自定義步驟。 AFAIK沒有提供開箱即用的策略的容器（在我看來，容器不是容器的一部分，而是容器責任的外部配置）。
你稱之爲「啓發式」的方法就是我所說的約定。大多數IoC容器允許您覆蓋它們如何解析綁定，這意味着您可以引入任何您想要的約定。沒有我知道的默認約定。相反，大多數容器並不作爲他們的默認設置;這是你的工作，告訴他們如何解決類型，無論是通過配置文件或通過代碼。
我發現一個自定義約定的例子很常見，它爲您節省了大量的聲明：如果請求的類型是以「I」開頭並以「Service」結尾的接口類型，則嘗試創建並解析類型與「I」不同，名稱相同。這將自動解析IFooService到FooService之間的名稱。另外，您可以引入邏輯來輕鬆地在不同的上下文中決定不同的服務，並且您可以在一個共同的地方處理服務實例的生命週期。
由於您可以覆蓋大多數IoC容器的綁定方式，因此您還可以引入其他行爲。但是，總的來說，真的有兩個選擇：
由於我使用StructureMap頗有幾分我知道該怎麼做這樣的事情與容器：這將主要是一個自定義登記公約（從初始化或註冊表，進入Scan-lambda模塊並找到「Convention」方法）。
它允許您查看反射類型，然後將它們插入到容器配置中，只要您認爲合適。它應該允許你正在嘗試做的事情。
Unity和Ninject也支持基於約定的配置（與大多數其他着名的IoC容器一樣）。 –
Unity 2.0不支持基於約定的配置。當我寫我的書時，我與Chris Tavares（Unity的架構師）通信，他確認它不支持自動註冊。 –
你對Unity 2.0沒有立即開箱即用的支持是正確的，但是你可以更容易地使用基於約定的方法。 'IUnityContainer.RegisterType'，所以它可以（很容易）完成。事實上，這是我們目前項目中的一個。 –