ASP MVC DependencyResolver 与 UnityContainer 用于单元测试
我正在构建一个 ASP MVC 3 应用程序，其中使用 Unity 作为 IOC 容器，并将其注册到 DependencyResolver 上。在我的控制器中，我可以这样做：
DependencyResolver.Current.GetService(GetType(IViewAllPersonsHandler))
然后，当我编写单元测试时，我在测试中重新定义映射以使用模拟对象。
我的一位同事告诉我，这样做被认为是反模式。
谁能告诉我是否是这样以及为什么？
我知道通常我应该在构造函数中注入依赖项，但是随着我的控制器的增长，构造函数参数会变得很长。
谢谢
I'm building an ASP MVC 3 application in which I use Unity as IOC container and I register it on the DependencyResolver. In my controller I can then do this:
DependencyResolver.Current.GetService(GetType(IViewAllPersonsHandler))
Then when I write my unit tests I redefine my mappings in my test to use mocked objects.
A colleague of mine told me that doing this is considered as an Anti Pattern.
Can anyone tell me whether this is the case and why?
I know that normally I should inject my dependencies in the constructor, but as my controller grows the constructors parameters get lengthy.
Thx
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
大多数人认为服务定位器模式是一种反模式。可能是因为人们可以通过一些跑腿工作来绕过它。
如果您这样做是为了限制构造函数参数，您可以尝试不同的方法。我使用属性注入。由于我使用温莎城堡，容器默认注入公共属性。最后我发现 Unity 没有这样做，你必须使用一些扩展才能使其工作。
除此之外，您可以拆分控制器或委托给操作中的任务。
但我也会远离控制器内的服务定位器。
华泰
Most folks consider the service locator pattern an anti-pattern. Probably since one can get around it with some leg-work.
If you are doing it to limit the constructor parameters you could try something different. I use property injection. Since I use castle windsor the container injects public properties by default. Last I looked Unity did not do this and you had to use some extension to get that to work.
Other than that you could split your controller or delegate to tasks within your actions.
But I would also stay away from service locator from within you controller.
HTH
您可以使用 System.Web.Mvc.DependencyResolver.SetResolver(resovlveDependencyMock);
You can use System.Web.Mvc.DependencyResolver.SetResolver(resovlveDependencyMock);
使用起订量很容易：
It's easy with Moq: