Why is IDependencyResolver closely related to System.Web?
Why is the reason IDependencyResolver
related to assembly System.Web
(either Mvc
or Http
) in the .NET framework?
The purpose of a DI system is not that it should provide an agnostic way of serving dependencies to the client? What if I want to use IDependencyResolver
in a project that shouldn't reference anything related to System.Web ?
Edit:
This is more of a philosophical question than a request on how to do this, because I know there are other alternatives like the open source DI library.
source to share
The purpose of a DI system is not that it should provide an agnostic way of serving dependencies to the client?
This is correct, but in this case it IDependencyResolver
depends on the library where it is defined. It is an abstraction of the DI library, allowing an agnostic extensive point to resolve dependencies. And I believe that was the original purpose of the abstraction.
There was really no need to reuse other libraries, which is obvious in the fact that there are two versions for MVC . and Web API . Although they have the same name and have the same purpose, their implementation is slightly different.
It also demonstrates the Conforming Container anti-pattern as mentioned in this article by Mark Seman where the article mentions abstractions above as well-known examples of Conforming Containers for .NET. Even my preferred approach to use IServiceProvider
made a list.
What if I want to use
IDependencyResolver
in a project that should not reference anything related to System.Web?
My suggestion then would be not to use IDependencyResolver
from System.Web. I would also like to add that, above all else, special attention should be paid to the following correct design patterns, making sure you understand the concepts and where they should be applied or avoided.
source to share
The interface IDependencyResolver
is the extension point of the System.Web system frameworks. Frameworks rely on this interface to resolve instances (controllers and the like) and their dependencies.
The framework has its own implementation of an interface, but you can provide your own implementation of that interface. The built-in implementation has limited functionality (foreign configuration, injection types, interception).
Most of the IOC-Container and DI-Framework provide an implementation of this interface, so you can integrate them into your existing infrastructure.
source to share
Why is the reason the IDependencyResolver is related to the System.Web Assembly (either Mvc or Http) in the .NET framework?
Because that is the interface they use to solve frame services. But yeah ... they should at least use IServiceProvider
from the namespace System
.
The purpose of a DI system is not that it should provide an agnostic way of customer dependence?
Nope. This is not a goal in this context. The main goal of the author of the framework is to allow you to extend or even replace the structure of internal services.
In your code, you must provide your own facades above these "standard" interfaces. These are very weak abstractions - good for the base, but very far from any better solution or lifecycle management strategies.
What if I want to use an IDependencyResolver in a project that shouldn't reference anything related to System.Web?
You can't (without adding a link System.Web
) and you shouldn't. Use your own internal abstraction (facade) over the DI framework. Just like you shouldn't use NLog.ILogger
directly in your classes, the same goes for DI frame abstractions.
Some frameworks will make it close or simply impossible, but you should use your own Facades where possible.
The same rules apply in a broader sense. Don't join your project (unnecessarily) to some cloud services like Azure. One day the other side may have much better prices. Limit addictions and sticky parts as much as possible.
Edit: This is more of a philosophical question than a request for how to do this, because I know there are other alternatives like the open source DI library.
Oh ... and the same guidelines come with the DI framework. Don't overuse DI frame functions, which can easily be implemented differently across your facades.
NOTE. The same happens with: CI pipelines, Service Bus / Message Queue frameworks.
source to share