在ASP.NET核心依赖注入（vNext） [英] Dependency Injection in ASP.NET Core (vNext)

问题描述

由于目前是DI的话题缺乏文档 - 依赖注入。有人可以帮助我了解以下内容：

1. 什么是这些注册区别呢？

    公共无效ConfigureServices（IServiceCollection服务）
   {
       services.AddTransient＆LT; IService，服务及GT;（）;
       services.AddScoped＆LT; IService，服务及GT;（）;
       services.AddSingleton＆LT; IService，服务及GT;（）;
       services.AddInstance（服务）;
   }
    



2. 什么是使用内置的DI超喜欢（NInject，Autofac，结构图）？现有的解决方案优点/缺点


3. 什么是（如果有的话），默认的依赖注入的电流限制？

解决方案

有关后面的SOLID原则的任何显着规模的应用产品的研发，vNext的内置DI容器将是无用的，因为：

• 它不会帮你验证您的配置，使得它真的很难诊断是来自共同的错误配置问题，如的圈养依赖的。在一个合理规模的应用程序，它实际上相当难以察觉自己的这些错误。


• 这是不可能申请使用拦截器或装饰横切关注点。这使得维护任何合理大小的应用程序确实很贵。


• 虽然它支持开放式通用的抽象映射打开通用的实现，它是无法与泛型类型与类型约束工作。

有其他限制内置容器，<击>如只能够支持类型与单个构造，但是这是一个非常合理的默认的，因为您的注射只应该有一个构造函数反正。自RC1，现在有一些多构造函数的支持。

如果你开始一个新的和简单的项目，我的建议是申请纯DI （这意味着手连线组件，而无需使用一个容器），并通过在自定义IControllerActivator 。后来，当功能，如批量注册和装修会改善你的成分根可维护性，切换到适合您的要求建立DI图书馆之一。

As currently there is lack of documentation on DI topic - Dependency Injection. Can someone help me to understand following:

1. What is the difference between these registrations?

   public void ConfigureServices(IServiceCollection services)
   {
       services.AddTransient<IService, Service>();
       services.AddScoped<IService, Service>();
       services.AddSingleton<IService, Service>();
       services.AddInstance(service);
   }
   

2. What are pros/cons of using built-in DI over existing solutions like (NInject, Autofac, Structure Map)?
3. What are current limitations of default dependency injection (if any)?

解决方案

For product development of any considerably sized application that follows the SOLID principles, vNext's built-in DI container will be useless, because:

• It doesn't help you in verifying your configuration, making it really hard to diagnose problems that come from common misconfigurations, such as Captive Dependencies. In a reasonably sized application, it's actually quite hard to spot these mistakes yourself.
• It is impossible to apply cross-cutting concerns using interceptors or decorators. This makes maintaining any reasonably sized application really expensive.
• Although it supports mapping of open generic abstractions to open generic implementations, it is unable to work with generic types with type constraints.

There are other limitations to the built-in container, such as only being able to support types with a single constructor, but this is a very reasonable default, because your injectables should only have a single constructor anyway. since rc1, there is now some kind of multi-ctor support.

If you start with a new and simple project, my advice is to apply Pure DI (which means hand-wired components without the use of a container) and resolve your types by plugging in your custom IControllerActivator. Later on, when features such as batch-registration and decoration would improve maintainability of your composition root, switch to one of the established DI libraries that fits your requirements.

这篇关于在ASP.NET核心依赖注入（vNext）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！