如何从 MSDN 教程中重构出 IDependencyResolver答案

【问题标题】：How to refactor out IDependencyResolver from MSDN tutorial如何从 MSDN 教程中重构出 IDependencyResolver
【发布时间】：2012-02-28 07:37:19
【问题描述】：

msdn (source) 的教程建议使用 IDependencyResolver：

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

我的印象是 IDependencyResolver 没有正确管理对象生命周期，因为它缺少释放方法，而且这在概念上是一种服务定位器反模式 (source)。

如何重构 this tutorial 以不使用 IDependencyResolver？

【问题讨论】：

为什么要重构一个教程？您是出于学习目的使用本教程还是将其改编用于生产代码？
@PaulKeister - 两者兼而有之，主要是想弄清楚如何正确设置 Unity 容器。

标签： asp.net-mvc-3 dependency-injection unity-container

【解决方案1】：

使用 Unity.Mvc3，有一个 HierarchicalLifetimeManager 可以管理实现 IDispoable 的对象的生命周期。

如果您仅在此处的组合根处解析，这不是一种反模式，这基本上与 MVC 是通过控制器中的构造函数注入。

http://blog.ploeh.dk/2011/07/28/CompositionRoot.aspx

请注意，这不一定是您创建的自定义控制器工厂，unity 会自动为您注入。在这里查看我的代码： http://completedevelopment.blogspot.com/2011/12/using-dependency-injection-with-mvc.html

【讨论】：

我认为只应在组合根目录进行注册，然后在需要时进行解析/释放。当你说解决时，你的意思是注册，还是我错过了什么？我的印象是，在一个地方解决所有依赖关系，然后从其他地方引用它们，这就是服务定位器反模式的定义。
解析是在组合根目录完成的，而不是注册。这是在应用程序启动时完成的。如果您在应用程序中的任何位置解析，但尽可能靠近请求的入口点（您可以控制的地方），那么您就有了服务定位器反模式。关键是您尽可能接近请求解决，对于 MVC 控制器，这是我提到的地方，除非进行绑定注入或其他注入（您可以在 mvc 中解析一堆类型 - 控制器、模型绑定器、验证器等）
我实际上知道您链接的代码（它的编码非常好）。在考虑这个问题时，我打开了这个项目，因为我正在寻找比 MSDN 更好的东西。在您的示例（上面链接）中，似乎只有注册是在引导程序中完成的，这是最佳实践。但是，我不明白为什么会有 UnityDependencyResolver1 来解析所有类型。你能解释一下吗？
此外，在 Mark 的博客（和书）中，他建议重写 IControllerFactory 以便在进入期间组合依赖项。
如果我记得我有这个是因为其他一些决议正在进行中。我认为在那个例子中（如果没有我这里有包含它的代码）我还注入了一个从这个线程产生的模型验证器依赖项：stackoverflow.com/questions/7743854/… 在这种情况下你不能在控制器级别注入但仍然在第一个点可通过 mvcs 集成获得。如果您使用服务进行验证并希望注入它以使其更具可测试性，这将是一个可行的方案。