CODEWITHSUNDEEP
c#asp.net.netasp.net-mvcasp.net-web-api
John-Philip
John-Philip

Reputation: 3520

Why is IDependencyResolver tightly coupled with System.Web?

Why is the reason the IDependencyResolver is coupled with the System.Web assembly (either Mvc or Http) in the .NET framework ?

The goal of a DI system isn't that it should provide an agnostic way of serving dependencies to a customer ? What if I want to use IDependencyResolver in a project that should not reference anything related to System.Web ?

Edit:
This is more a philosophical question than a request about how to do, because I know there are other alternatives such as open source DI library.

Upvotes: 3

Views: 788

Answers (3)

Nkosi
Nkosi

Reputation: 247213

The goal of a DI system isn't that it should provide an agnostic way of serving dependencies to a customer ?

That is correct, but in this case, IDependencyResolver is specific to the library where it is defined. It is that library's DI abstraction to allow an agnostic extensibitliy point for dependency resolution. And I believe that that was the initial goal of the abstraction.

It was not really made to be reused independently by other libraries, which is evident in that there are two versions for both MVC and Web API. Though they share the same name and have the same purpose, their implementations differ slightly.

It also demonstrates the Conforming Container anti-pattern as mentioned in this article by Mark Seemann, where the article also mentions the above abstractions as known examples of Conforming Containers for .NET. Even my preferred approach of using IServiceProvider made the 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 to not use IDependencyResolver from System.Web. I would also add that above all, particular attention should be payed to following proper design patterns, making sure that one has an understanding of the concepts and where they should be applied or avoided.

Upvotes: 6

Arek Bal
Arek Bal

Reputation: 733

Why is the reason the IDependencyResolver is coupled with the System.Web assembly (either Mvc or Http) in the .NET framework ?

Because it is an interface 'they' use to resolve framework services. But yeah... they should, for the very least, have used IServiceProvider from System namespace.

The goal of a DI system isn't that it should provide an agnostic way of serving dependencies to a customer ?

Nope. That is not the goal in that context. The main goal for framework author is to let you extend or even replace internal services framework is using.

In your code you should introduce your own facades over these 'standard' interfaces. They are very weak abstractions - good for base, but very far away from any richer resolving or lifetime management strategies.

What if I want to use IDependencyResolver in a project that should not reference anything related to System.Web ?

You cannot (without adding System.Web reference) and you shouldn't. Use your own internal abstraction(Facade) over DI framework. Just like you shouldn't use NLog.ILogger directly in your classes, same applies to DI framework abstractions.

Some frameworks will make it close to or just impossible to do but you should use your own Facades wherever possible.

Same rules apply in broader sense as well. Don't attach your project (unnecessarily) to some cloud service such as Azure. Other side might have much better prices some day. Limit dependencies and sticky parts as much as possible.

Edit: This is more a philosophical question than a request about how to do, because I know there are other alternatives such as open source DI library.

Oh... and same advice go with DI frameworks. Don't overuse DI framework features that could be easily implemented in different way over your Facades.

NOTE: Same goes with: CI pipelines, Service Bus/Message Queue frameworks.

Upvotes: 2

Jehof
Jehof

Reputation: 35544

The interface IDependencyResolver is an extension point of the System.Web-frameworks. The frameworks rely on this interface to resolve instances (of controllers and their like) and their dependencies.

The framework has its own implementation of the interface, but you can provide your own implementation of this interface. The Built-in implementation has a limited functionality (external configuration, injection types, interception).

Most IOC-Container and DI-Frameworks provide an implementation of this interface, so that you can integrate them into the existing framework.

Upvotes: 2

Related Questions