Value of dependency injection in MVC with skinny controllers

Question

Dependency injection is often recommended in MVC projects because it's easy to implement with the pattern and adds a host of potential benefits. Indeed, it actually comes bundled with the default MVC project in Visual Studio.

If you read around MVC, however, you will also see a lot of people recommending the use of skinny controllers. In other words your controller does little more than act as a bridge between the display engine and the business logic. All the processing work is instead done by the models and helper classes.

But if you're using skinny controllers, is there any need for DI? Surely in this case, handling things like a repository or a file helper should be done outside the controller?

Or to put it another way, what I'm asking is that if you've got skinny controllers, shouldn't there be no need for those controllers to have external dependencies? No dependencies, no need to mock them for tests, so no need for DI. Indeed I've seen some arguments that you shouldn't unit test skinny controllers at all, because there's almost no logic in them.

Is there any value in adopting both approaches?

Answer 1

Dependency injection is often recommended in MVC projects because it's easy to implement with the pattern and adds a host of potential benefits

I would argue that dependency injection is recommended generally in projects (not just MVC) because of the benefits it brings in terms of decoupling and testability. There's nothing specific to an MVC pattern. As such I would adopt DI generally.

Indeed I've seen some arguments that you shouldn't unit test skinny controllers at all, because there's almost no logic in them.

I would disagree with this. I don't know what constitutes 'almost no logic' but you want to test your code to determine that it does what you want initially, and that it continues to do what you want in the face of subsequent modifications/additions (to ensure you're not introducing regressions)

Answer 2

Yes there is value because it allows you to unit test your controllers.

The business layer and model should know nothing about http so the job of the controller is translating the business layer to a web world.

Example:

• Exception Y was thrown should result in http status 4xx
• Precondition A was not met. Redirect to Abc

So even if the controller is skinny it has still work to do. Unit testing that work becomes possible by using DI.

Answer 3

Let's just assume for a minute that it is perfectly fine to skip DI with sknny controllers. Now what about the rest of your application?

Dependency Injection as a technique is proven to be immensely useful and valuable. As others have noted, it encourages a more decoupled design which improves testability. These are extremely valuable perks!

MVC or no MVC, Dependency Injection is a generally good idea.

So, even if doesn't apply to your skinny controllers it almost definitely applies to the rest of your application.