SubControllers solved a big problem for us when we first started our current project.  I posted about them back in the day.

The problem was isolating authorization to view sections of a page.  In other words, if you didn’t have permission X, you couldn’t see the top-left section of the screen.  If you didn’t have permission Y, you couldn’t see top-right section of the screen.  By composing the controllers that decided how to display the sections, we could test drive nicely each controller’s authorization check and subsequent decision.

Later we embraced the ViewModel concept and are working with strongly-typed views.  We found that using SubControllers wasn’t the best approach in that situation, for a couple reasons:

First, that the view properly invokes the SubController remains untested.  The responsibility for performing the interaction still rests with the view.  So why not just make the authorization check in the view? 

That’s the other problem: scattered partial views can be a small maintenance headache.  In our current project, after embracing the ViewModel, there just wasn’t a pain that SubControllers cured.

We didn’t abandon SubControllers because they didn’t work, or because there was a flaw in the implementation, or because they were too complex, or anything like that.  They may still be the right approach for a given screen.

If you’re unsure how to share view pieces in your application, refer to Jimmy’s excellent guide.