IDependencyResolver是反模式吗？

Question

IDependencyResolver是反模式吗？

mic*_*lpm 19 c# asp.net-mvc dependency-injection service-locator

我正在为遗留的ASP.NET应用程序设计一些体系结构更改.我为一些模拟ASP.NET MVC的IDependencyResolver的依赖项解析的类做了原型.我不会发布,因为它几乎是相同的界面,但用其他自然语言.

我发现它可能被认为是服务位置,反过来通常(在某些情况下不完全)被谴责支持依赖注入.尽管如此,我找不到任何反对使用ASP.NET MVC的依赖项解析实现的建议.

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

Answer 1

Mar*_*ann 26

如果您查看签名,您将看到它只是一个具有其他名称的服务定位器.Service Locator是一种反模式,我认为这种关系是传递的,所以我认为IDependencyResolver是一种反模式.

除此之外,界面也被破坏,因为它没有Release方法.

虽然我同意马克关于服务定位器反模式的事情.但是,无论您尝试什么,在您的应用程序中必须至少有一些使用Service Locator(反)模式的地方,因为我们需要以某种方式解析实例.在MVC中,他们通过让框架本身解析根对象(控制器)来有效地解决了这个问题.为此,我们需要为MVC提供一个容器,并将`IDependencyResolver`定义为抽象.那么`IDependencyResolver`是一件坏事,因为它是服务定位器？我不这么认为. (13认同)
在回答这个问题时,或许应该区分在组合根中实现服务定位器和在整个代码中引用服务定位器. (9认同)
但是,自从1.0以来,ASP.NET MVC已经将IControllerFactory用于这个目的,并且它的目的令人钦佩.这是一个抽象工厂,所以大部分都是无害的. (8认同)
也许我们不同意如何使用IDependencyResolver.我永远不会鼓励人们在他们的代码中使用IDR.Resolve()而不是应用程序顶部的一个位置.这是在使用IDR时所假设的,我已经让所有课程都要求它了吗？我的天!我是构造函数注入的主要倡导者.我必须同意史蒂文的意见,因为必须解决某个地方的IControllerFactory.该框架最初是手动完成的,现在它使用IDR进行抽象,它也用于其他过去在框架中进行硬编码的东西. (4认同)
但是......那些是基于共享状态的可怕设计的例子!将口红放在猪身上并不能证明服务定位器是一个很好的模式.总有一种更好的方法来解决这样的问题. (3认同)
是的,ASP.NET MVC的那部分(以及某些其他部分)确实是可怕的设计. (2认同)
它不是:http://blog.ploeh.dk/2011/08/25/ServiceLocatorrolesvs.mechanics (2认同)
@MarkSeemann对不起,你不能两种方式,你是基于迂腐的论据.你真的应该重新评估你的观点.服务定位器只是一个有价值的模式,可以完成其他模式完成的角色.就像所有模式一样,它可能会被误用.你不能明确地说"这是一个反模式",然后立即在这里说同样的功能"但这不是服务定位器,所以它很好".如果它像鸭子一样走路,像鸭子一样呱呱叫,那就是鸭子......或者模仿鸭子的东西. (2认同)

Answer 2

小智 8

我不相信......你可以将你想要的任何IoC注入到ASP.NET MVC中,这对我来说似乎是一个非常好的模式.

这是一篇关于将Unity注入ASP.NET MVC 3 的博客文章.

归档时间：	14 年，5 月前
查看次数：	10873 次
最近记录：	14 年，5 月前