我见过像 Ninject 这样的框架以及 Stack 上的帖子谈到使用依赖注入框架时的自绑定,如下面的代码所示。
Bind<Samurai>().To<Samurai>();
他们甚至为此使用了特殊的语法:
Bind<Samurai>().ToSelf();
为什么要将类型绑定到自身?我没有看到任何实际应用程序可以说明这可能有用并有助于减少代码中的依赖性。这难道不意味着对类型的引用会简单地解析为自身吗?
当应用依赖注入并遵守依赖倒置原则,常见的建议是对接口进行编程,而不是对实现进行编程。这就是为什么大多数时候您会看到从抽象到实现的绑定:
Bind<IWarrior>().To<Samurai>();
这意味着组件depend on IWarrior
在编译时,当你inject a Samurai
在运行时。
然而,在某些条件下,从具体组件到其自身的映射是有意义的。换句话说,如果“某人”需要Samurai
,你提供它Samurai
.
最突出的情况是解析根类型时。根类型位于依赖图的顶部;根类型直接从容器解析。所有其他组件都是根类型的直接或间接依赖项。
通常,您会看到这些根类型由其具体类型解析,例如在处理 UI 框架时就会发生这种情况。 Web 表单就是这样的例子Page
s, MVC Controller
s、Web APIApiController
s, etc.
某些 DI 容器允许无论如何解析具体的未注册类型(尽管近年来一些 .NET 的 DI 容器默认禁用了解析具体未注册类型的功能)。这可能会让您相信自我约束是多余的,但情况并非总是如此。显式添加此类绑定可以让容器知道此类绑定的存在。这样做的优点是可以使用容器的诊断功能(如果存在)来扫描对象图以查找错误。如果缺乏此类功能,通常可以迭代已知的注册并在单元测试中进行一些验证。为了使此类验证在容器的注册被迭代时有意义,所有根类型都需要在容器中注册。否则此验证过程将导致漏报。
您想要告诉 DI 容器有关自绑定的另一个原因是,当您需要使用与容器的默认生活方式不同的生活方式来注册类型时。大多数容器会给你一个短暂的实例,以防类型未注册。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)