我正在为旧版 ASP.NET 应用程序设计一些架构更改。我对一些模仿 ASP.NET MVC 的 IDependencyResolver 的依赖关系解析类进行了原型设计。我不会发布,因为它几乎是相同的界面,但使用其他自然语言。
我发现它可能被认为是服务位置,这反过来通常(在某些情况下不完全)被谴责以支持依赖注入。然而,我找不到任何反对使用 ASP.NET MVC 的依赖解析实现的建议。
ASP.NET MVC 的 IDependencyResolver 是否被视为反模式?这是一件坏事吗?
我正在为旧版 ASP.NET 应用程序设计一些架构更改。我对一些模仿 ASP.NET MVC 的 IDependencyResolver 的依赖关系解析类进行了原型设计。我不会发布,因为它几乎是相同的界面,但使用其他自然语言。
我发现它可能被认为是服务位置,这反过来通常(在某些情况下不完全)被谴责以支持依赖注入。然而,我找不到任何反对使用 ASP.NET MVC 的依赖解析实现的建议。
ASP.NET MVC 的 IDependencyResolver 是否被视为反模式?这是一件坏事吗?
如果您查看签名,您会发现它只是一个具有另一个名称的服务定位器。Service Locator 是一种反模式,我认为这种关系是可传递的,所以我认为IDependencyResolver 是一种反模式。
除此之外,接口也被破坏了,因为它没有 Release 方法。