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?