design-patterns - 为什么在未开发的 ASP.Net MVC 应用程序中使用提供程序模型会让人感觉倒退？

Question

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

我试图找到一个使用提供程序模型的良好工作流程，但每次我真正开始编码时，主要感觉模式正在妨碍我，感觉就像我分心整理配置陷阱并将 copypasta 静态外观拼凑在一起当我可以完成工作时。

现在我开始了一个小型的 ASP.Net MVC 绿地项目，并发现一些团队成员对采用 DI 框架有抵抗力。

我知道 DI 框架感觉比针对提供程序模型编写更快、更容易，但每次我试图阐明原因时都会陷入细节中。

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

Answer 1

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

另一方面，依赖注入(inject)只是 the most efficient way to enable loose coupling 。如果您想编写 可维护代码 ，这是实现该目标的最有效方法之一。

然而，大多数人倾向于抵制 DI，因为它“感觉”在倒退，但这确实是一个人需要克服的事情。