C# （自动）依赖项注入绑定机制

创建依赖项注入绑定的两种常见机制（例如通过IOC容器）来自XML配置或命令代码块。在这些情况下，键-值对是显式的（即键=请求的类型，值=返回的类型）

尽管如此，还有第三种“启发式”方法，其中应用程序/IOC容器只被赋予[IMyClass]键，然后容器会在一组应用程序程序程序集依赖项上进行反射，以找到所有名称匹配的具体类[MyClass]。换言之，“返回类型”值是发现的，而不是声明的

我想知道两个方面：

哪些IOC容器（或其他后期绑定工具）允许启发式方法？这种方法有更通用的名称吗

除了我列出的三种绑定技术之外，还有其他在实践中使用的绑定技术吗

---

我通常是按照你所说的在配置中的自定义步骤来做的。好了，没有一个容器提供了开箱即用的策略（在我看来，这不是容器的一部分，而是一种配置的东西，应该是容器责任之外的东西）。

你所说的“启发式”方法就是我所说的约定。大多数IoC容器允许您覆盖它们解析绑定的方式，这意味着您可以引入任何您想要的约定。据我所知，没有这样的默认约定。相反，大多数容器默认不做任何事情；您的工作是告诉他们如何通过配置文件或代码解析类型

我发现的一个自定义约定的示例非常常见，它为您节省了大量声明：如果请求的类型是以“I”开头、以“Service”结尾的接口类型，则尝试创建并解析除“I”之外的同名类型。这将自动将

IFooService

等名称解析为

FooService

。此外，您可以引入逻辑，在不同的上下文中很容易地决定不同的服务，并且可以在公共位置处理服务实例生命周期

由于可以覆盖大多数IoC容器绑定的方式，因此还可以引入其他行为。但是，通常有两种选择：

在运行时配置（通过XML文件等配置文件）

在编译时进行配置（通过类似于声明性DSL的API或通过自定义约定或其他形式的自定义逻辑）

---

由于我已经使用了StructureMap很多次，我知道如何使用该容器做这样的事情：它基本上是一个自定义注册约定（从初始化或注册表开始，进入Scan lambda块并找到“约定”方法）

---

它允许您查看反射的类型，然后根据需要将它们插入容器配置中。它应该允许您尝试执行的操作。

这称为基于约定的配置或自动注册，由以下.NET DI容器支持：

DI容器最常用的配置机制有

• XML
• 代码作为配置
• 基于约定的配置

---

第四种（但不常见）方法是使用属性。Unity和Ninject也支持基于约定的配置（与大多数其他著名的IoC容器一样）。Unity 2.0不支持基于约定的配置。在我写这本书的时候，我与Chris Tavares（Unity的架构师）进行了通信，他确认Unity不支持自动注册。Unity 2.0没有即时的现成支持，你是对的，但是你可以很容易地使用一种基于约定的方法，例如利用

IUnityContainer.RegisterType

，所以它可以（很容易地）完成。事实上，这就是我们在当前项目中所做的。