What is the best way to split up MVC controller functionality?

Question

Hi,

When making Controllers, what are the best ways to split it up?

If I have an admin section that has a bunch of .ascx web user controls underneath it and a few .aspx pages. Should I have one AdminController? Or should I have a Controller for each individual admin pages/web user controls?

It seems as though being responsible for a single page's actions goes against one of the things MVC was trying to improve on from Web Forms. But at the same time, you don't want one Controller for your entire website...

I understand what Controllers are supposed to do, but how much should one individual Controller be responsible for? What are the best methods for splitting up the responsibility of Controllers?

Thanks,
Matt

Answer 1

One AdminController is a good choice. Different methods in the controller have different responsibilities within the Admin feature set, and different views when appropriate.

You can see this division of labor at work in the Nerddinner project.

Answer 2

Totally a 75% answer, but as a very flexible answer, one controller per model and then just give it enough flexibility to create, read, update, and delete that model (preferably keeping the interface consistent across controllers and avoiding special case interfaces unless absolutely necessary.)

This works for all cases except the the ones for which it doesn't!

REST is a pretty good framework for thinking about this. While the following guide is targeted towards the way rails does it, a lot of the concepts should be applicable more broadly http://www.softiesonrails.com/2007/3/28/rest-101-part-1-understanding-resources