Why does using provider model in a greenfield ASP.Net MVC app feel backwards?

Question

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?

Answer 1

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.

Answer 2

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