1

The tutorial by the msdn (source) recommends using an IDependencyResolver:

 IDependencyResolver resolver = DependencyResolver.Current;
 IDependencyResolver newResolver = new UnityDependencyResolver(container, resolver);
 DependencyResolver.SetResolver(newResolver);

I was under the impression that IDependencyResolver does not properly manage object lifetime because it lacks a release method, and also that is conceptually a service locator anti-pattern (source).

How could I refactor this tutorial to not use IDependencyResolver?

Community
  • 1
  • 1
Travis J
  • 81,153
  • 41
  • 202
  • 273
  • Why bother refactoring a tutorial? Are you using the tutorial for learning purposes or adapting it for use in production code? – Paul Keister Feb 06 '12 at 20:37
  • @PaulKeister - A little of both, mostly trying to figure out how to properly set up the Unity container. – Travis J Feb 06 '12 at 20:38

1 Answers1

2

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

Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71
  • I thought only registration should be done at the composition root, and then resolving/releasing should be done when needed. When you said resolve, did you mean register, or am I missing something? It was my impression that resolving all the dependencies in one place and then referencing them from elsewhere was the definition of the service locator anti pattern. – Travis J Feb 06 '12 at 21:00
  • resolving is done at the composition root, not registration. That is done upon app startup. If you resolve anywhere in your application but as close to the entry point of the request as possible (where you have control), then you have the service locator anti-pattern. The point is you resolve as close to the request as possible, which for MVC controllers is where I mentioned unless doing binder injection or other injection (there are a bunch of types you can resolve in mvc - controllers, model binders, validators, etc) – Adam Tuliper Feb 06 '12 at 21:01
  • I am actually aware of the code you linked (it is very well coded). I had the project open when considering this question because I was looking for something better than what MSDN had. In your example (linked above) it seems that only the registering is done in the bootstrapper which is best practice. However, I do not understand why you would have UnityDependencyResolver1 which resolves all types. Can you explain that a little? – Travis J Feb 06 '12 at 21:16
  • Moreover, in Mark's blog (and book) he suggests to override the IControllerFactory in order to compose dependencies during entry. – Travis J Feb 06 '12 at 21:19
  • If I recall I had that in place because of some other resolutions going on. I think in that example (if not I have the code here that would contain it) I'm also injecting a model validator dependency spawned from this thread: http://stackoverflow.com/questions/7743854/asp-net-mvc-3-validating-model-when-information-external-to-the-model-is-requir in this case you cant inject at the controller level but still at the first point available via mvcs integration. If you are using a service for validation and want to inject this to make it much more testable, this would be a viable scenario. – Adam Tuliper Feb 07 '12 at 05:20
  • Ideally I'll turn that into an all encompassing injection demo for every area of injection for mvc, just havent made the time yet : ) – Adam Tuliper Feb 07 '12 at 05:20