为什么在全新的 ASP.Net MVC 应用程序中使用提供程序模型感觉很落后？
我最近从一个在 ASP.Net MVC 中使用 Ninject 进行依赖项注入的团队转变为一个除了 ASP.Net 2.0 中引入的提供程序模型模式之外对 IoC 解决方案一无所知的团队。
我试图找到一个很好的工作流程来处理提供者模型，但每次我真正进行编码时，主要感觉是模式妨碍了我，而且感觉我在整理配置陷阱和拼凑复制粘贴静态外观时分心了当我可以完成工作时。
现在，我正在启动一个小型 ASP.Net MVC 绿地项目，并发现一些团队成员对采用 DI 框架存在阻力。
我知道 DI 框架感觉比针对提供者模型编写更快、更容易，但每次我试图阐明原因时，都会陷入细节之中。
任何人都可以描述这两种方法之间的客观差异，以及为什么在容器可以轻松引导的环境中针对提供者模型进行编写似乎很奇怪？
I've recently gone from a team using Ninject in ASP.Net MVC for dependency injection to a team that knows nothing of IoC solutions besides the provider model pattern that was introduced in ASP.Net 2.0.
I've tried to find a good workflow for working with provider model, but everytime I really get coding, it mainly feels like the pattern is getting in the way and it feels like I get distracted sorting out configuration gotchas and cobbling together copypasta static facades when I could be getting work done instead.
Now I'm starting a small ASP.Net MVC greenfield project, and finding resistance from some of the team members to adopting a DI framework.
I know that DI frameworks feel faster and easier than writing against provider model, but get stuck in details each time I try to articulate why.
Can anybody describe the objective differences between the two approaches and why writing against provider model in an environment where a container could easily be bootstrapped in seems just strange?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Provider 习惯充其量只是一种设计味道。最好完全避免它。
另一方面，依赖注入只是实现松散耦合的最有效方法< /a>.如果您想编写可维护的代码，这是实现该目标的最有效方法之一。
然而，大多数人倾向于抵制 DI，因为它“感觉”倒退，但这确实是人们需要克服的事情。
The Provider idiom is, at best, a design smell. It's best to avoid it completely.
Dependency Injection, on the other hand, is simply the most efficient way to enable loose coupling. If you want to write maintainable code, it's one of the most effective ways to achieve that goal.
However, most people tend to resist DI because it 'feels' backwards, but it's really something one just needs to get over.
我认为推销的方法可能是，如果您希望能够对代码进行单元测试，则需要将所有依赖项从您正在测试的内容中抽象出来。您可以使用提供者模型来做到这一点，但这意味着通过提供者的需求比您可能想要处理的要多得多。
假设您有一个应用程序调用一些外部第三方服务，但也有一个本地数据库。您的控制器有时调用“提供者”（用于外部服务），但有时调用本地数据库的“存储库”。那么，您将如何对调用存储库的方法进行单元测试呢？我想您需要通过提供者将整个本地数据库抽象出来。在这种情况下，您要么最终得到一两个巨大的提供程序实现（糟糕的设计，每个类有太多方法），要么最终得到一大堆小型提供程序（配置噩梦）。
使用 IOC 容器，您可以在代码本身中完成大部分连接。使用模拟框架使单元测试变得容易。因此，如果您确实愿意，您可以使用 Provider 进行“外部调用”，使用 IOC 进行“内部调用”。
我正在考虑这个问题，因为我们在提供程序中有很多遗留代码，我正在考虑摆脱它们并直接使用 IOC。我相信 AutoFac 等 IOC 容器可以复制能够通过配置“插入”不同实现的要求，因此您不会真正丢失任何东西。
在我的博客文章中阅读更多内容 - 希望该博客也能得到一些好的评论：http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html
I think the way to pitch it might be that if you want to be able to unit test your code, you need to abstract all dependencies away from what you are testing. You can do that with the provider model but it means a whole lot more needs to go through providers than you probably want to deal with.
Lets say you have an application that calls some external 3rd party services but also has a local database. Your controllers are sometimes calling a "Provider" (for the external services) but sometimes calling a "repository" for the local database. So how are you going to unit test the methods that call a repository? I guess you need to abstract your whole local database out through providers. In this case you will either end up with one or two huge provider implementationn (poor design to have too many methods per class), or you will end up with a whole lot of small providers (configuration nightmare).
With an IOC container, you can do most of the wiring up in the code itself. Using a mocking framework makes Unit Testing easy. So if you really want, you can use Providers for "external calls" and IOC for "internal calls".
I am just in the process of thinking about this because we have a lot of legacy code in providers and I am thinking of moving away from them and just using straight IOC. I believe IOC containers such as AutoFac can replicate that requirement of being able to "plug in" a different implementation via configuration, so you are not really losing anything.
Read more on my blog post - hopefully the blog will get some good comments about it too: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html