Why is the use of the provider model in the new ASP.Net MVC application felt back?

Question

I recently moved from a team using Ninject in ASP.Net MVC for dependency injection to a team that knows nothing about IoC solutions other than the provider model template introduced in ASP.Net 2.0.

I tried to find a good workflow for working with the provider model, but every time I really get the coding, basically it looks like the template is getting in the way, and it seems to me that I'm distracted by sorting the configuration and chobbling copypasta static facades when I could get a job, not.

Now I am starting a small ASP.Net MVC project, and putting up some team resistance to accept the DI framework.

I know that DI frameworks feel faster and easier than writing against a provider model, but dwell on the details every time I try to state why.

Can someone describe the objective differences between the two approaches and why writing to a vendor model in an environment where the container can load easily seems just weird?

Answer 1

The idiom of a provider is, at best, a designer smell . This is best avoided.

Dependency injection, on the other hand, is simply the most effective way to enable free communication . If you want to write supported code , this is one of the most effective ways to achieve this.

However, most people tend to resist DI because it "feels" backward, but it really is something that you just need to overcome.

Answer 2

I think that the way to pass this can be, if you want to be able to unit test your code, you need to distract everything depending on what you are testing. You can do this with a vendor model, but that means there is so much more to go through vendors than you probably want to deal with.

Suppose you have an application that calls some external third-party services, but also has a local database. Sometimes your controllers call the "provider" (for external services), but sometimes they call the "repository" for the local database. So, how are you going to use unit test methods that invoke the repository? I think you need to divert your entire local database through providers. In this case, you will either end up with one or two huge provider implementations (poor design to have too many methods for each class), or you will have many small providers (configuration nightmare).

With an IOC container, you can do most of the wiring in the code itself. Using a fake frame simplifies unit testing. Therefore, if you really want this, you can use the Providers for "external calls" and the IOC for "internal calls".

I just think about it because we have a lot of legacy code in the providers, and I think about moving away from them and just use the direct IOC. I believe that IOC containers such as AutoFac can replicate this requirement in order to “plug in” another implementation through configuration, so you don’t lose anything.

More about my blog post - I hope the blog will also get good comments about it: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html