Is Idependencyresolver an Anti-Pattern

Is IDependencyResolver an anti-pattern?

If you look at the signature you will see that it's just a Service Locator with another name. Service Locator is an anti-pattern and I consider the relationship transitive, so I consider IDependencyResolver an anti-pattern.

Apart from that, the interface is also broken because it has no Release method.

Difference between implementing DI by extending DefaultControllerFactory vs implementing IDependencyResolver

Stick with DefaultControllerFactory.

IDependencyResolver is an example of the Service Locator anti-pattern, and should, IMO, never have been added to MVC (or Web API, for that matter). Although many people confuse Service Location and Dependency Injection, they are two extremely different attempts to solve some common problems related to programming to interfaces.

However, when you weigh the advantages and disadvantages of Service Locator versus DI, you'll find that Service Locator truly is an anti-pattern, because it introduces far more problems than it solves. Although it purports to solve some problems, it actually doesn't solve any problems that DI can't solve better.

Why is MVC4 using the Service Locator Anti-Pattern?

That's an implementation detail that you shouldn't care about. The important thing is that now that the Web API uses the DependencyResolver to resolve dependencies for many different facilities, you will be able to use a real dependency injection whenever you want to plug into those facilities. So in your code you will be using a real dependency injection. If Microsoft didn't use the DependencyResolver then it would have been you that must have used it (as a service locator anti-pattern) in your code in order to resolve dependencies when you want to implement some custom functionality. This would have been bad for you. Now it's bad for Microsoft but you don't care about them.

Thus I'm left curious and confused why Microsoft would use a service locator in 2012.

Because designing a framework is not the same as designing an application using a framework. There are some different things to take into consideration when designing a reusable framework such as ASP.NET MVC rather than just what's written in the books. Some example is to design the framework in such a way that a person using this framework will be able to take advantage of the best practices written in the books in his code using this framework.

Is is an anti-pattern to inject DI container to (almost) each class?

Absolutely wrong. Don't put the DI container in the objects; they need not know or care that they're being injected. This doesn't square with "don't call us; we'll call you."

It's the other way 'round: the overall app knows about the DI engine, but then it gets the beans it needs from it.

I suppose you might argue that annotations change the relationship some, because now the beans do know something about the fact that they're wired together. But when configuration was externalized into XML, it was true that beans were ignorant of DI.

How to refactor out IDependencyResolver from MSDN tutorial

Use Unity.Mvc3, there is a HierarchicalLifetimeManager that can manage lifetime for objects implementing IDispoable.

Its not an anti pattern if you resolve only at the composition root here, which basically with MVC is via constructor injection in the controller.

http://blog.ploeh.dk/2011/07/28/CompositionRoot.aspx

Note this doesn't have to be a custom controller factory you create, unity will inject automatically for you. See my code here:
http://completedevelopment.blogspot.com/2011/12/using-dependency-injection-with-mvc.html

DefaultControllerFactory vs IDependencyResolver

Pedant note first. You cannot inherit from an interface (IDependencyResolver) but I assume you mean implement.

In short you have a choice between using either, you would not use both. So if you have the resolver set up you do not need to have a controller factory and vice versa.

I have only used DefaultControllerFactory in mvc with castle-windsor. You will need to be wary of one loose end in using IDependencyResolver if you are using castle-windsor also, there is no release method but there are probably ways around this.

With other frameworks such as ninject or unity IDependencyResolver is sometimes preferable.

When does the IDependencyResolver start his job in the asp.net lifecycle?

I think it is fairly early in the MVC pipeline the DependencyResolver get instantiated. MVC framework internally use the DependencyResolver. As you know the DependencyResolver finds and create instance of Controllers, during the Controller creation. Which is right after the IRouteHandler i.e MvcRouteHandler get invoked - fairly early in the life cycle.

But it is well after the HttpModules get created, I think you are out of luck using the DependencyResolver to register HttpModules.

I don't think you cannot customize the scope of the IDependencyResolver. It is just Service Locator type container which helps you to plugin your own dependency resolution mechanism.

Yes IDependencyResolver is an anti-pattern and I personally don't like it. Actually
Mark Seemann has a really good article on the IDependencyResolver. I'm sure this would point you to the right direction.

You better off using the Composition Root pattern to register dependencies in a single location.

What dependency injection pattern to use for a MessageProvider?

To anyone who might be looking for the same answer in the future, I decided to use Ambient Context for this because of the reasons I mentioned in the quesiton.

---

Related Topics