IDependencyResolver 是反模式吗？答案

【问题标题】：Is IDependencyResolver an anti-pattern?IDependencyResolver 是反模式吗？
【发布时间】：2011-08-04 22:58:21
【问题描述】：

我正在为旧版 ASP.NET 应用程序设计一些架构更改。我对一些模仿 ASP.NET MVC 的 IDependencyResolver 的依赖关系解析类进行了原型设计。我不会发布，因为它几乎是相同的界面，但使用其他自然语言。

我发现它可能被认为是服务位置，这反过来通常（在某些情况下不完全）被谴责以支持依赖注入。不过，我找不到任何反对使用 ASP.NET MVC 的依赖解析实现的建议。

ASP.NET MVC 的 IDependencyResolver 是否被视为反模式？这是一件坏事吗？

【问题讨论】：

IDependencyResolver 只是一个工具；它的使用方式是模式。将其等同于服务定位器模式过于简单化了。不要从代码中引用它，并坚持构造函数注入。

标签： c# asp.net-mvc dependency-injection service-locator

【解决方案1】：

如果您使用另一个名称查看signature you will see that it's just a Service Locator。 Service Locator is an anti-pattern 并且我认为这种关系是可传递的，所以我认为 IDependencyResolver 是一种反模式。

除此之外，接口也是broken because it has no Release method。

【讨论】：

虽然我同意 Mark 关于服务定位器反模式的观点。但是，无论您尝试什么，您的应用程序中至少必须有某个地方使用服务定位器（反）模式，因为我们需要以某种方式解析实例。在 MVC 中，他们通过让框架本身解析根对象（控制器）有效地解决了这个问题。为此，我们需要为 MVC 提供一个容器，并且 IDependencyResolver 被定义为对此的抽象。那么IDependencyResolver 是个坏事，因为它是服务定位器吗？我不这么认为。
但是，自 1.0 以来，ASP.NET MVC 已经为该目的提供了 IControllerFactory，而且它的目的非常出色。它是一个抽象工厂，所以基本上是无害的。
也许我们对如何使用 IDependencyResolver 存在分歧。我永远不会鼓励人们在他们的代码中使用 IDR.Resolve()，而不是应用程序顶部的一个位置。这就是使用 IDR 时的假设，我的所有课程都在向它索要东西吗？不！我是构造函数注入的大力倡导者。我必须同意 Steven 的观点，即必须在某个地方解决 IControllerFactory 问题。该框架最初是手动完成的，现在它使用 IDR 将其抽象为它还用于框架中过去硬编码的其他内容。
在回答这个问题时，也许应该区分在组合根中实现服务定位器和在整个代码中到处引用服务定位器。
但是......这些都是基于共享状态的可怕设计的例子！给猪涂口红并不能证明 Service Locator 是一个好的模式。总有更好的方法来解决此类问题。

【解决方案2】：

我不这么认为...你可以将任何你想要的 IoC 注入 ASP.NET MVC，这对我来说似乎是一个很好的模式。

Here's a blog post 关于将Unity 注入 ASP.NET MVC 3。

【讨论】：

IDepedencyResolver 好像实现了服务定位。问题是：是吗？为什么这个实现比其他服务定位器更好？
@michelpm: It doesn't implement anything.
@michelpm 目的是创建一个通用接口，以便您可以使用 IOC 容器以完全与容器无关的方式处理 MVC 控制器的对象图构造。该接口创建契约，因此 MVC 实现可以遵循“魔术给我东西”方法。如果没有这种模式，您将需要构建自己的基础框架进行依赖倒置。