2

Can somebody shine a little light for me?

I've got my website all running using Windsor Castle. I have a controller factory and installers for controllers and services. All nice.

Now I've just created a IDependencyResolver implementing class called WindsorDependencyResolver with a straigh-forward implementation:

public class WindsorDependencyResolver : System.Web.Mvc.IDependencyResolver
{
    private readonly IKernel _kernel;

    public WindsorDependencyResolver (IKernel kernel)
    {
        _kernel = kernel;
    }

    public object GetService(Type serviceType)
    {
        return _kernel.Resolve(serviceType);
    }

    public IEnumerable<object> GetServices(Type serviceType)
    {
        return _kernel.ResolveAll(serviceType) as IEnumerable<object>;
    }
}

I've got it setup like so (global.asax):

DependencyResolver.SetResolver(new WindsorDependencyResolver(kernel));

And now what? When is this 'used'? Should I stop using kernel.Resolve(someType)?

danyolgiax
  • 12,798
  • 10
  • 65
  • 116
Ropstah
  • 17,538
  • 24
  • 120
  • 194

2 Answers2

2

My understanding is the IDependencyResolver is what is used internally by MVC 3 to do Service Location/Inversion of Control. So in order for your Controllers to get instantiated properly, and be able to inject whatever dependencies you have, you need to tell MVC how to talk to the container your using (Windsor in your case).

You would still want to use kernel.Resolve(someType) when you need to get something out of the container that is not injected for you via constructor/property injection.

Interestingly, the MSDN documentation points to Brad Wilson's Blog Post on the IDependencyResolver for details.

ckramer
  • 9,419
  • 1
  • 24
  • 38
  • So this means that **I** will not use the DependencyResolver for things other than MVC3 internal services? – Ropstah May 29 '11 at 16:36
  • 1
    It's intent is to allow MVC to use your container of choice. I guess you could use it yourself, but it's an extra layer of abstraction that you probably don't need to worry about in your code. – ckramer May 31 '11 at 17:34
2

It sounds like you already have a custom IControllerFactory. If so, just stick with it. It's a much better solution than the hack that is IDependencyResolver (which has lots of problems).

Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
  • I actually read about this before... But away from technical imperfections, what's going on here? What if I register another `IDependencyResolver` implementing class? How will the container behind `DependencyResolver.SetResolver()` know which one to use if they have overlap in the services they provide? – Ropstah May 29 '11 at 20:22
  • -1 Sorry to reply so late, but I think the conclusion of Mike Hadlows post is wrong. IDependencyResolver is not intended to be used by client code, rather it is intended to simplify extension of MVC. – Daniel Lidström Nov 03 '11 at 16:39
  • 1
    If so, why is there a public Singleton through which it can be accessed? And why is MVC 3 being touted by Microsoft as 'now supporting DI'? – Mark Seemann Nov 03 '11 at 17:04