设计模式 – 为什么在绿地ASP.Net MVC应用程序中使用提供者模型感觉倒退？

我最近从使用Ninject在ASP.Net MVC中进行依赖注入的团队变成了一个除了ASP.Net 2.0中引入的提供者模型模式之外对IoC解决方案一无所知的团队.

我试图找到一个良好的工作流程来处理提供者模型,但每次我真正得到编码,它主要感觉就像模式正在阻碍我感到分心,整理配置陷阱和cobbling copypasta静态外观当我可以完成工作时.

现在我正在开始一个小型的ASP.Net MVC绿地项目,并发现一些团队成员对采用DI框架的阻力.

我知道DI框架比编写提供者模型更快更容易,但每次我试图阐明原因时都会陷入细节.

任何人都可以描述这两种方法之间的客观差异,以及为什么在容器可以轻松引导的环境中针对提供者模型进行编写似乎很奇怪？

解决方法

Provider idiom is,at best,a design smell.最好完全避免它.

另一方面,依赖注入只是the most efficient way to enable loose coupling.如果你想编写可维护的代码,它是实现这一目标的最有效方法之一.

然而,大多数人倾向于抵制DI,因为它“感觉”倒退,但它确实是一个人们需要克服的东西.