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

Question

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

仍然有第三种“启发式”方法，其中应用程序/ IOC容器仅被赋予[IMyClass]键，然后容器反映一组应用程序组件依赖项以查找所有名称匹配的具体类[MyClass]。换句话说，发现“返回类型”值而不是声明。

我想知道的是双重的：

1. 哪些IOC容器（或其他后期绑定工具）允许启发式方法？这种方法有更常见的名称吗？
2. 除了我列出的三个在实践中使用的其他绑定技术吗？

Answer 1

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

我发现的一个自定义约定的例子很常见，可以为你节省很多声明：如果请求的类型是以“I”开头并以“Service”结尾的接口类型，那么尝试创建并解析一个类型与“我”相同的名字。这样可以自动将IFooService等名称解析为FooService。此外，您可以引入逻辑来轻松地决定不同上下文中的不同服务，并且您可以在一个公共位置处理服务实例的生命周期。

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

1. 在运行时配置（通过配置文件，如XML文件）
2. 在编译时配置（通过声明性的类似DSL的API或通过自定义约定或其他形式的自定义逻辑）

Answer 2

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

• Castle Windsor
• StructureMap
• Autofac

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

• XML
• 代码配置
• 基于会议的配置

第四种但不常见的方法是使用属性。 Managed Extensibility Framework是这种方法最突出的例子，在Java中更为常见。

Answer 3

我通常会将您描述的内容描述为会议中的自定义步骤。 AFAIK没有提供开箱即用的容器这样的策略（在我看来，它不是容器部分，而是容器责任外部的配置东西）。

Answer 4

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

它允许您查看反射的类型，然后根据需要将它们插入容器配置中。它应该允许你想要做的事情。