c# - (自动)依赖注入绑定机制




.net dependency-injection (3)

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

尽管如此,还有第三种“启发式”方法,其中应用程序/ IOC容器只有[IMyClass]键,然后容器反映了一组应用程序组件依赖关系,以查找所有名称匹配的具体类[MyClass]。 换句话说,“返回类型”值是被发现的而不是被声明的。

我想知道的是双重的:

  1. 哪些IOC容器(或其他后期绑定工具)允许启发式方法? 这种方法有一个更常见的名字吗?
  2. 除了我列出的三个实践中,还有其他的绑定技术吗?

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

我发现一个自定义约定的例子是相当普遍的,它为您节省了大量的声明:如果请求的类型是一个以“I”开始并以“Service”结尾的接口类型,则尝试创建并解析具有相同名称的类型除了“我”之外。 这将自动将名字IFooServiceFooService 。 另外,您可以很容易地引入逻辑在不同的上下文中决定不同的服务,并且可以在一个普通的地方处理服务实例的生命周期。

由于您可以覆盖大多数IoC容器的绑定方式,因此也可以引入其他行为。 但是,一般来说,有两个选择:

  1. 在运行时进行配置(通过XML文件等配置文件)
  2. 在编译时进行配置(通过声明式DSL类API或通过自定义约定或其他形式的自定义逻辑)

因为我已经使用了很多的StructureMap,所以我知道如何用这个容器做这样的事情:它基本上是一个自定义注册约定(从初始化或注册表,进入Scan-lambda块,找到“约定“ 方法)。

它允许您查看反射的类型,然后将其插入到容器配置中,只要您认为合适。 它应该允许你正在做的事情。


这称为基于约定的配置自动注册 ,并由这些.NET DI容器支持:

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

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

第四种但不常见的方法是使用属性。 托管扩展性框架是这种方法中最突出的例子,这在Java中更为常见。





late-binding