我真的已经进入了DI / IoC的事情 - 它使一些事情变得容易多了。但是,我有一些继承的类实现了一个带有必需的无参数构造函数的类,因此我使用服务定位器来获得我想要的东西:
MyMembershipProivder() : MyMembershipProvider(ServiceLocator.Current.GetInstance<...>){}
MyMembershipProivder(IMemberRepo memberRepo){...}
完美的作品。但是,由于我也在使用MVC3 DependencyResolver,我发现自己别无他法:
var locator = new NinjectServiceLocator(kernel);
DependencyResolver.SetResolver(locator);
ServiceLocator.SetLocatorProvider(() => locator);
在MVC应用程序中使用DependencyResolver,并在各种类库中使用ServiceLocator。
这是理想的做法吗?我错过了什么吗?
更新
在上面的示例中,该类是一个自定义的asp.net mebership提供程序。 asp.net成员资格提供程序工厂要求我的自定义提供程序具有无参数构造函数,迫使我使用服务定位器注入它在内部使用的存储库。
答案 0 :(得分:2)
您不需要无参数构造函数,Dependency Resolver会将您的依赖项注入构造函数:
MyMembershipProivder(IMemberRepo memberRepo){...}
您可以替换默认控制器工厂(在控制器中使用无参数构造函数):
ControllerBuilder.Current.SetControllerFactory(new NinjectControllerFactory());
您无需更换默认控制器工厂,请参阅下面的Linkgoron评论。
无论如何,使用我的MVC应用程序的依赖关系解析器和类库的服务定位器都很好,我想。
希望这有帮助。
答案 1 :(得分:0)
似乎你没有真正的选择,除非你可以从一开始就重构你的应用程序以使用DI。所以,我想使用自定义服务定位器是你最好的选择。
虽然,如果您“继承”的类是控制器类,您可以删除默认构造函数并完成它,因为MVC将为您处理所有内容。
我从未见过ServiceLocator类,是this?
编辑:
正如我所说,我没有看到你有任何其他选择去耦。服务地点可能是您最好的选择,而不会引入太多膨胀和复杂性。
作为内置于.Net FW内容的东西,您应该寻找特定的解决方案,例如为会员提供商提供的解决方案。