为什么要在内置的ASP.NET Core DI容器上使用第三方DI容器? [英] Why would one use a third-party DI Container over the built-in ASP.NET Core DI Container?

问题描述

目前缺少有关DI主题的文档-依赖注入.在现有解决方案(如Ninject，Autofac，StructureMap)上使用内置DI的利弊是什么?以及默认依赖项注入(如果有)的当前限制是什么?

As currently there is lack of documentation on DI topic - Dependency Injection. What are pros/cons of using built-in DI over existing solutions like (Ninject, Autofac, StructureMap)? And what are current limitations of default dependency injection (if any)?

另外，有人可以帮助我了解这些注册之间的区别吗?

Additionally, can someone help me to understand 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);
}

推荐答案

对于采用松散耦合并遵循SOLID原则的任何大小合理的应用程序的产品开发，.NET Core的DI容器都不适合，因为:

For product development of any reasonably sized application that practice loose coupling and follows the SOLID principles, .NET Core's DI container is unsuited, because:

• 它无法帮助您验证配置，因此很难诊断出常见配置错误引起的问题.在合理大小的应用程序中，您自己很难发现这些错误. 更新:MS.DI的版本3现在包含名为ValidateOnBuild的功能，但它唯一要做的就是检查是否可以创建所有注册.
• 不可能使用拦截器或应用交叉切割问题 ="https://en.wikipedia.org/wiki/Decorator_pattern" rel ="nofollow noreferrer">装饰器以可维护的方式.这使得维护任何大小合理的应用程序确实非常昂贵. 更新:有几个第三方库试图填补这一空白，但是由于MS.DI中的限制，它们无法完全填补这一空白(例如，修饰开放式基因注册)
• 尽管它支持将开放泛型抽象映射到开放泛型实现，但是它的实现天真，并且无法实现可以处理具有类型约束，更复杂的泛型映射和差异的泛型类型.
• 进行条件/上下文注册是不可能，这样的方式是仅将注册注入到特定的一组消费者，同时使用自动布线.例如当具有两个都依赖于ILogger的两个成分Service1和Service2时，您可能想将Service1与NullLogger注入，将Service2与FileLogger注入，或者希望将Service1注入Logger<Service1>和Service2与Logger<Service2>.

• It doesn't help you in verifying your configuration, making it really hard to diagnose problems that come from common misconfigurations. In a reasonably sized application, it's actually quite hard to spot these mistakes yourself. UPDATE: Version 3 of MS.DI now contains a feature called ValidateOnBuild, but the only thing it does is check whether all registrations can be created.
• It is impossible to apply Cross-Cutting Concerns using interceptors or decorators in a maintainable fashion. This makes maintaining any reasonably sized application really expensive. UPDATE: There are several third-party libraries that try to fill the gap, but due to limitations in MS.DI, they can't completely fill this gap (e.g. decorate open-gemeric registrations)
• Although it supports mapping of open-generic abstractions to open-generic implementations, its implementation is rather naive and is unable to work with generic types with type constraints, more complex generic type mappings, and variance.
• It is impossible to make conditional/contextual registrations, in such way that registrations only get injected to a certain set of consumers, while using Auto-Wiring. e.g. when having two components Service1 and Service2 that both depend on ILogger, you might want to inject Service1 with NullLogger and Service2 with FileLogger, or you want Service1 to be injected with Logger<Service1> and Service2 with Logger<Service2>.

存在这些限制的主要原因是因为内置容器的目标是为框架本身提供DI功能，同时将其功能设置为最小，以期希望有更多成熟的DI容器成为可能.能够与之整合.换句话说，它会作为最小公分母(LCD)进行尝试.由于具有LCD功能，因此它永远无法成长为适合应用程序开发的功能完善的DI容器(并非不违反成为LCD的承诺).

The main reason for those limitations to exist is because it's the goal of the built-in container to provide DI capabilities to especially the framework itself, while keeping its feature set to a minimum in the hope that more mature DI containers would be able to integrate with it. In other words, it tries to act as an Least-Common Denominator (LCD). Because of its LCD function, it can never grow to a full-fletched DI Container that is practical for application development (not without breaking the promise of being an LCD).

如果您从一个新的简单项目开始，我的建议是应用纯DI .这意味着您可以使用容器和没有创建您自己的 DI容器.相反，您可以通过插入

If you start with a new and simple project, my advice is to apply Pure DI. This means you hand-wire components inside the Composition Root without using a container and without creating your own DI Container. Instead you resolve your types by plugging in your custom IControllerActivator. Later on, when features such as Auto-Wiring, Auto-Registration and Interception would improve maintainability of your Composition Root, switch to one of the established DI libraries that fits your requirements.

这篇关于为什么要在内置的ASP.NET Core DI容器上使用第三方DI容器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！