1

I've really gotten into the DI/IoC things - it makes some things a lot easier. However, I have a few inherited classes that implement a class with a required parameterless constructor, I thus use a service locator to get what I want:

MyMembershipProivder() : MyMembershipProvider(ServiceLocator.Current.GetInstance<...>){}
MyMembershipProivder(IMemberRepo memberRepo){...}

Works perfect. However, since I'm also using MVC3 DependencyResolver I find myself no other way but to do:

var locator = new NinjectServiceLocator(kernel);
DependencyResolver.SetResolver(locator);
ServiceLocator.SetLocatorProvider(() => locator);

DependencyResolver gets used within the MVC app and the ServiceLocator gets used throughout the various class libraries.

Is this the ideal way to do this? Am I missing something?

Update

In the example above, the class is a custom asp.net mebership provider. The asp.net membership provider factory requires for my custom provider to have a parameterless constructor, forcing me to use the service locator to inject the repository that it uses internally.

Tony Basallo
  • 3,000
  • 2
  • 29
  • 47

2 Answers2

2

You don't need the parameterless constructor, the Dependency Resolver will inject your dependency into the constructor:

MyMembershipProivder(IMemberRepo memberRepo){...}

You can replace the default controller factory (to use parameterless constructors in your controllers):

ControllerBuilder.Current.SetControllerFactory(new NinjectControllerFactory());

You wont need to replace the default controller factory, see Linkgoron's comment below.

Anyway using the Dependency Resolver for your MVC application and the Service Locator for your class libraries is fine, I think.

Hope this helps.

Kalman Speier
  • 1,937
  • 13
  • 18
  • 1
    You don't need to replace the default controller factory in MVC 3 for dependency injection. – Linkgoron Feb 26 '11 at 20:21
  • Hmm, I didn't know that, but actually makes sense, thanks for the comment. ;) – Kalman Speier Feb 26 '11 at 20:50
  • I updated the question, it's not for the controller. In this case the parameterless contructor is required. – Tony Basallo Feb 26 '11 at 22:52
  • About MembershipProvider and DI, see this http://stackoverflow.com/questions/1003587/how-to-integrate-ioc-membership-provider-with-asp-net-mvc/1004806#1004806 – Kalman Speier Feb 27 '11 at 09:59
  • thanks, that's an interesting solution. But at the end of the day, they're still using a ServiceLocator and created another class (ProviderFactory). I do not think there's a way around the ServiceLocator - just hoping to use one and not two. – Tony Basallo Feb 28 '11 at 13:34
0

It seems as if you don't really have a choice, unless you can refactor your application to use DI from the start. So, I guess using custom a Service Locator is your best bet.

Although, if the classes you've "inherited" are the controller classes you can just remove the default constructors and be done with it, as MVC will handle everything for you.

I've never seen the ServiceLocator class, is it this?

EDIT:

As I've said, I don't see that you have any other option for decoupling. Service location is probably your best bet, without introducing too much bloat and complexity.

Stuff that's implemented as something built into the .Net FW you should look for specific solutions like the one presented for the Membership Provider.

Linkgoron
  • 4,866
  • 2
  • 26
  • 26
  • Yes, thats the same one I'm using. I've updated the question. As you can see I need the ServiceLocator to find the service to be injected using the overloaded constructor. – Tony Basallo Feb 26 '11 at 22:54