Why would one use a third-party DI Container over the built-in ASP.NET Core DI Container?

Why would one use a third-party DI Container over the built-in ASP.NET Core DI Container?

回答1

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:

• 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.
• 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.
• 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>.

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).

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

 

回答2

Here it is explained :

• Transient - A new instance is created every time
• Scoped - A single instance is created inside the current scope. It is equivalent to Singleton in the current scope
• Singleton - A single instance is created and it acts like a singleton
• Instance - A specific instance is given all the time. You are responsible for its initial creation

Alpha version had this limitations :

• It only supports constructor injection
• It can only resolve types with one and only one public constructor
• It doesn’t support advanced features (like per thread scope or auto discovery)

If you aren't writing really complicated product default DI container should be sufficient for you. In other cases you can try libraries you already mentioned that have advanced features.

My advice would be to start with the default one and change implementation when(if) you hit something you can't do with it.

 

 

作者:Chuck Lu    GitHub