What is the difference between DependencyResolver.SetResolver and HttpConfiguration.DependencyResolver in WebAPI

Question

I have existing project, which uses AutoFac as IoC.

In the registration code i have these lines:

var resolver = builder.Build();
DependencyResolver.SetResolver(new AutofacDependencyResolver(resolver));
config.DependencyResolver = new AutofacWebApiDependencyResolver(resolver);

So my question is what is the difference between DependencyResolver.SetResolver and HttpConfiguration.DependecyResolver? Why should I assign both of them?

Solution 1

Prevent mixing MVC and Web API in the same project. Microsoft seems to suggest this, because the Visual Studio template for Web API mixes the project automatically with MVC, but this is a bad idea.

From an architectural point of view, MVC and Web API are completely different. MVC is a UI technology aimed to optimize end user experience. Web API is a web service technology that is aimed to optimize the experience for the (client) developer.

MVC and Web API don't share any presentation specific code. Mixing them in the same project just makes that project bigger and more complicated.

But perhaps even more importantly, both application types have their own DI configuration needs. They have their own Composition Root and mixing that into a single DI configuration (a single DI container) can make your configuration extraordinary hard.

And last, mixing Web API with MVC in the same project leads to painful ambiguous naming conflicts, since Web API assemblies contains a lot of classes that share the exact same name as MVC counterparts (but with slightly different implementations).

Solution 2

I guess you mixed up between MVC and Web API:

DependencyResolver.SetResolver

is for MVC and belongs to assembly System.Web.Mvc. Otherwise:

Configuration.DependencyResolver

for Web APi, it belongs to assembly System.Web.Http.

So, in your project, it uses both MVC and Web Api, that is why you see two lines to configure IoC for each

Solution 3

DependencyResolver.SetResolver is an MVC construct and is required to support IOC using MVC.

The GlobalConfiguration.Configuration.DependencyResolver is WebApi specific.

You you will only need both if you want to support both MVC and WebApi within the same project.

It is may also be worth pointing out that you do not normally need to explicitly set the DependencyResolver.SetResolver as the Ninject Mvc3 has a bootstrap for this... see here

Comments

[Jevgenij Nekrasov]

Ok, but let's say I need to save some additional data before running WebApi, in that case I want to use my DAL layer from global.asax and want it to be injected. I don't really see any problems in mixing/reusing the same DI configuration in that case? Web API project is completely separated.

[Steven]

It's very common for multiple end applications to reuse the same business layer or other shared assemblies. If you find yourself duplicating code in both the MVC and Web API project, you're missing a shared assembly. For some parts the DI configurations look a like and the DRY principle still holds here: prevent duplication by extracting that part to a shared assembly and let each end application complete the configuration in a way that suits its needs.

[Yann Duran]

@Steven - answers like this are really not helpful at all, & I've voted it down for that reason. Mark's explanation was all that was really required (explaining the difference between the two revolvers), & I've voted it up for that reason as well. Unless Jevgenij's question has had it edited out, MVC wasn't even mentioned at all in it, AutoFac was.

[Yann Duran]

this was also a succinct & appropriate answer for the question asked, so I've voted it up as well.

[Radenko Zec]

Check this article to see how to share container between two projects in very elegant way blog.developers.ba/simple-way-share-container-mvc-web-api

[Steven]

@RadenkoZec: Sure, but sharing the same container instance is not the issue. When the project changes you'll see that different cross-cutting concerns need to be applied around the business layer based on whether it is a Web API request or an MVC request. This complicates your DI configuration tremendously and your solution does not make that easier. There's only one way to make that easier, have two containers, preferably in two separate applications.

[rism]

It's amazing how quickly things date. Now with MVC 6 just around the corner WebApi has been directly integrated into MVC.

[Steven]

@rism: I don't think things have dated, since most of the arguments still stand: 1. From an architectural point of view, MVC and Web API are completely different. 2. MVC and Web API don't share any presentation specific code. 3. Both application types have their own DI configuration needs. Only the last point about the painful ambiguous naming conflicts will go away with MVC6.

[Jack]

@Steven Many thanks for answer. I had to make so many search in order to get an acceptable idea (because as you said lots of the web sites mixed up both of them). So, I will create a new separate project for WebAPI (I currently have an UI Layer (MVC) and Data Layer (Class Library) in my application. So, I also use DI, but I am wondering if I can use the same Entities, Repositiries, Interfaces and Abstract classes in the Data Layer for the newly created WebAPI project and the only thing I have to do create WebAPI Controllers? Or do I also create all of them again for the WebAPI? Any help please

[Steven]

@H.Johnson it would be awful and a rude violation of DRY to duplicate that. Of course you should reuse the same business layer project.

[jpaugh]

While providing some really good high level points, this post goes out of its way not to answer the actual (low-level) question.

[Kellen Stuart]

So... you're saying it is possible to support both in the same project? How do you do that?