Why does MVC4 use an anti-pattern locator?

Question

After reading Mark Seemann's Dependency Injection in .NET, I stay away from the Service Locator , which is an anti-pattern.

After reading the MVC 4 release notes, I see:

Improved Management Inversion (IoC) through DependencyResolver: The web API now uses the service locator pattern implemented by the MVCs resolver dependency to retrieve instances for many different objects.

Thus, I am left curious and confused about why Microsoft will use the service locator in 2012.

Answer 1

This is an implementation detail that you should not care about. The important thing is that now that the web API uses DependencyResolver to resolve dependencies for many different objects, you can use a real dependency injection when you want to connect to these tools. Thus, in your code you will use a real dependency injection. If Microsoft did not use DependencyResolver , then you should have used it (as an antivirus) in your code to resolve dependencies when you want to implement some user-defined functions. That would be bad for you. Now this is bad for Microsoft, but you do not care about them.

Thus, I am left curious and confused about why Microsoft will use the service locator in 2012.

Because designing a structure is not the same as designing an application using a framework. When designing a reusable framework such as ASP.NET MVC, there are several different things to consider, not just what is written in the books. Some example is the development of a structure so that a person using this structure can use the best practices written in books in his code using this infrastructure.

Answer 2

As Darin points out, ASP.NET MVC 4 is a Framework and is a container agnostic. Therefore, it provides a service locator in the form of an IDependencyResolver . This allows anyone to connect their own container of choice.

However, I would not call it an anti-pattern. This allows you to use the container of your choice, but it does not force you to the application developer to use the location of the service. If the structure forced the developer to use Service Location, I would call it an anti-template. But the developer who creates the ASP.NET MVC application is free to use DI through the installation of a constructor, property settings, or service location. This is their choice.

Check out all MVC MVC MVC implementation examples published by me or the ASP.NET MVC team. In almost all cases, they use constructor injection. They do not use the location of the service.

In fact, most of the ASP.NET MVC source code itself does not use the location of the service to extract dependencies. There are a few key places where MVC calls a service locator for legacy APIs, etc. But about that.