Dependency injection in ASP.NET WebAPI: IHttpControllerActivator vs. IDependencyResolver

Question

Recently I came across this discussion.

In ASP.NET WebAPI, when we need to integrate a custom inversion of control/dependency injection container, we need to go with two different strategies:

1. Implement IHttpControllerActivator, which is an extension point to fully control controller's life-cycle. That is, we can define how a controller is instantiated. At this point, we can resolve the controller using an inversion of control container and let it use its own dependency injection approach.

2. Implement IDependencyResolver, where we can define how to resolve dependency injections.

In my current projects I went the IHttpControllerActivator way, and since I'm using Castle Windsor as inversion of control container, I can fully control object life cycle from its container configuration, and I can decide how controllers are resolved, and the scope of its recursively-injected dependencies defining that they die once the controller ends its life (i.e. when the request ends).

While some of these features can be achieved with IDependencyResolver implementations, I feel that IHttpControllerActivator is the best way to integrate inversion of control and dependency injection in ASP.NET Web API, because I believe that I prefer to stay as abstract as possible and stick with Castle Windsor configuration model in terms of inversion of control and dependency injection.

The main drawback with the IHttpControllerActivator approach is you need to register all controllers in the container while IDependencyResolver still gives the responsibility of resolving the controller to ASP.NET Web API pipeline (for me, this hasn't been a big issue, I just used Castle Windsor's Classes.FromAssembly to configure all controllers deriving ApiController).

Do I ignore any other drawbacks that would make the IDependencyResolver approach more appropiate?

Answer 1

The IHttpControllerActivator approach primarily has an advantage over the IDependencyResolver approach because of the context provided, as excellently described in the following blog post: http://blog.ploeh.dk/2012/09/28/DependencyInjectionandLifetimeManagementwithASP.NETWebAPI/.

However, in most easier scenarios, it simply does not pay back the extra effort to manually register everything. Using the IDependencyResolver approach in many situations just 'does the trick'. Add good documentation and the larger day to day user base to that, and I myself would probably consider if I could manage using IDependencyResolver before considering IHttpControllerActivator.