Why doesn't Asp.net web api controllers derive from IController

Question

In ASP.net MVC4 there's this 'new' concept of a web API for exposing CRUD functionality on your data model. The base class for these controllers is DataController which derives from from ApiController.

Unfortunately this ApiController doesn't derive from IController which is problematic since these requests can't be handled through your normal custom controller factory as these are supposed to return an instance of IController.

Does anyone know the reason behind this as I can't see why you would have a controller in your MVC project that doesn't derive from IController as this breaks your custom controller factory as it's not able to instantiate every single controller in your project.

In short, because of this inheritance you're unable to use your DI container to inject dependencies.

Answer 1

I sent this same question to Microsoft as well and got the following reply by Eilon Lipton (thx for that):

The short story is that while ASP.NET MVC and ASP.NET Web API share a lot of the same design concepts (dependency injection, lots of interfaces to plug in custom implementations, and easy testability), they build on different underlying HTTP stacks. MVC builds on the System.Web stack that has been used in ASP.NET for over 10 years. Web API builds on the new System.Net.Http stack which offers greater flexibility for hosting (IIS + custom hosts + unit test hosts) as well as better testability and extensibility. If you compare IController and IHttpController you’ll see that one uses System.Web up and down the stack, and the other doesn’t use it at all.

Regardless of any of this, all the technologies built on the ASP.NET stack – MVC, Web Forms, Web API, Web Pages (and Razor) – will continue to work side-by-side within an application, allowing you to choose the right pieces to build each part of your application. While individual implementations of components within each piece are not interchangeable, they can each be wired up to the same services, such as dependency injection systems, logging tools, data providers, and so forth.

Once we publish our post on this subject I think that should clarify things further.