IDependencyResolver是反模式吗？

Question

我正在对一款传统的ASP.NET应用程序进行一些架构上的改变。我原型化了一些类来实现依赖关系解析，这些类模仿了ASP.NET MVC的IDependencyResolver接口。我不会贴代码，因为这个接口在其他自然语言中也是非常相似的。

我想到它可能被认为是服务定位，而服务定位通常（在某些情况下不完全）被弃用以支持依赖注入。尽管如此，我找不到任何反对使用ASP.NET MVC依赖解析实现的建议。

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

- michelpm

---

IDependencyResolver只是一个工具，它的使用方式才是设计模式。将其等同于服务定位器模式是一种过度简化。不要在您的代码中引用它，坚持使用构造函数注入。 - StarTrekRedneck

Answer 1

如果你看一下签名，你会发现它只是另一个名字的服务定位器。 服务定位器是一种反模式，我认为这种关系是可传递的，因此我认为IDependencyResolver是一种反模式。

除此之外，这个接口还存在问题，因为它没有释放方法。

- Mark Seemann

---

尽管我同意Mark关于服务定位器反模式的观点。但是，无论你尝试什么，你的应用程序中至少必须有一些地方使用服务定位器(反)模式，因为我们需要以某种方式解决实例。在MVC中，他们通过让框架自己解析根对象(控制器)来有效地解决了这个问题。为了使其工作，我们需要向MVC提供一个容器，并且IDependencyResolver被定义为这个抽象。所以IDependencyResolver是不是一个坏东西，因为它是服务定位器？我不这么认为。 - Steven

然而，ASP.NET MVC 从 1.0 版本就有了 IControllerFactory，正是为了这个目的，而且它一直表现出色。它是一个抽象工厂，所以基本上没有什么危险性。 - Mark Seemann

也许我们对如何使用IDependencyResolver存在分歧。我从不鼓励人们在除了App顶部之外的代码中使用IDR.Resolve()。当使用IDR时，是否假定我有所有类都在向它请求东西？并不是！我非常支持构造函数注入。我必须同意Steven的看法，即必须在某个地方解析甚至是IControllerFactory。该框架最初是手动完成此操作的，现在使用IDR来抽象化，它还用于其他曾经在框架中硬编码的东西。 - StarTrekRedneck

回答这个问题时，也许应该区分在组合根中实现服务定位器和在代码中到处引用您的服务定位器。 - user74754

但是...那些都是基于共享状态的可怕设计示例！给猪涂口红并不能证明服务定位器是一个好的模式。总有更好的方法来解决这类问题。 - Mark Seemann

Answer 2

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

这里有一篇博客文章讲述了如何将Unity注入到ASP.NET MVC 3中。

- user1228

---

看起来IDepedencyResolver实现了服务定位。问题是：它真的实现了吗？为什么这种实现比其他服务定位器更好？ - michelpm

@michelpm: 它并没有实现任何东西。 - user1228

@michelpm，这个目的是创建一个通用接口，以便您可以使用IOC容器处理MVC控制器的对象图构建，而完全不涉及容器。该接口创建了合同，因此MVC实现可以推迟到“魔法给我东西”的方法。如果没有这种模式，您需要构建自己的基础框架来进行依赖反转。 - Chris Marisic