什么是IoC容器中的自绑定？ [英] What is self-binding in an IoC container?

问题描述

我看到像Ninject这样的框架以及Stack上的帖子，在使用依赖注入框架时，就像下面的代码一样，讲到自绑定。

I've seen frameworks like Ninject as well as posts on Stack speak about self binding when using dependency injection frameworks like in the code below.

Bind<Samurai>().To<Samurai>();

他们甚至会有特殊的语法：

They even go to the extent of having special syntax for this:

Bind<Samurai>().ToSelf();

为什么要将类型绑定到自己？我没有看到任何实际的应用程序，这可能是有用的，并有助于减少代码中的依赖。这不仅仅意味着对类型的引用会简单地解决自己吗？

Why would you want to bind a type to itself? I don't see any practical applications for where this might be useful and help reduce dependencies in code. Wouldn't this just mean a reference to a type would simply resolve to itself?

推荐答案

当应用依赖注入并遵守依赖性反转原则常见的建议是。这就是为什么大多数时候你会看到从抽象到实现的绑定：

When applying Dependency Injection and adhering to the Dependency Inversion Principle the common advice is to program to interfaces, not implementations. That's why most of the time you'll see bindings that go from an abstraction to an implementation:

Bind<IWarrior>().To<Samurai>();

这意味着组件将依赖于 IWarrior 在编译时，我们在运行时注入一个 Samurai 。

This means that components will take a dependency on IWarrior at compile time, and we inject a Samurai at runtime.

然而，在某些条件下，这是有道理的将具体组件映射到自身。换句话说，如果某人请求一个武士，我们将提供武士。

Under certain conditions however, it makes sense to have mapping from a concrete component to itself. In other words, in case 'someone' requests a Samurai, we supply it with that Samurai.

最突出的情况是解决根类型时。根类型是依赖关系图的顶部;根类型直接从容器中解析出来。所有其他类型都是根类型的直接或间接依赖关系。

The most prominent case is when resolving root types. Root types are the top of the Dependency Graph; root types are resolved directly from the container. All other types are direct or indirect dependencies of a root type.

通常，您将看到这些根类型由其具体类型解决，通常我们正在处理UI框架。例如Web窗体页面 s，MVC 控制器 s，Web API ApiController s等。

Often you'll see that those root types are resolved by their concrete types and often we're dealing with UI frameworks. Examples of such are Web Forms Pages, MVC Controllers, Web API ApiControllers, etc.

大多数DI容器可以让具体的未注册类型得到解决。这可能会导致您相信自我约束是多余的，但并不总是如此。添加这样的绑定明确地允许容器知道这样的绑定的存在。这具有使用容器的诊断能力（如果存在）来扫描对象图的错误的优点。在没有这样的特征的情况下，通常可以迭代已知的注册并在单元测试中进行一些验证。对于这种验证在容器的注册被迭代时是有意义的，所有的根类型都需要在容器中注册。否则，此验证过程将导致假阴性。

Most DI containers allow concrete unregistered types to be resolved anyway. This might lead you to believe that a self-binding is redundant, but that is not always the case. Adding such binding explicitly lets the container know about the existence of such binding. This has the advantage of using the container's diagnostic abilities (if present) to scan the object graphs for errors. In case of the absence of such feature, one can usually iterate the known registrations and do some verification inside a unit test. For such verification to be meaningful when the container's registrations are iterated over, all root types need to be registered in the container. Otherwise this verification process will result in false-negatives.

另一个为什么要告诉DI容器有关自绑定的原因是容器不允许解析时未注册的类型，或者当您需要使用与容器的默认生活方式不同的生活方式注册的类型时。大多数容器将为您提供一个瞬态实例，以防类型未注册。

Another reason why you want to tell the DI container about a self-binding is when the container doesn't allow resolving unregistered types, or when you need the type to be registered with a different lifestyle than the container's default lifestyle. Most containers will give you a Transient instance, in case the type isn't registered.

这篇关于什么是IoC容器中的自绑定？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！