ASP .NET MVC - Number of Controllers

Question

Should there be a separate controller for each table that needs to be manipulated in a system?

As an example, in designing an administration section of a content management system, should there be a separate controller for configuring each look up domain as follows:

/DataTypeA/List --list for A
/DataTypeA/Create -- create new data
.
. 
.
/DataTypeB/List --list for B

or should there just be separate actions within an Admin controller as follows

/Admin/DataTypeA -- this lists DataTypeA
/Admin/DatatypeB -- this lists DataTypeB
/Admin/DataTypeA_Create -- Create a new DataTypeA
/Admin/DataTypeB_Create -- Create a new DataTypeB

Answer 1

Basically it depends on what you're after and how you want to organize your code. If DataTypeA is distinctly different than DataTypeB (i.e. Animals vs. Automobiles) then you'd probably want to use different controllers. But, if DataTypeA is a subset of (or similar to) DataTypeB, then I'd use one controller with different actions.

ASP.NET MVC is so flexible it is very cool, though admittedly, at the beginning, the flexibility feels like you're drowning. Just start writing code and you'll realize if you're headed down the wrong path. There is a learning curve to MVC. Go with it.

Answer 2

I think it's largely a design choice. I don't think there's a clear-cut answer, although I guess if you were sticking to the letter of the pattern then you would go for the one-controller-per-datatype option.

I started to put together a small prototype blog system to try out ASP.NET MVC a little while ago (still a WIP, sadly), and one design decision I ended up making was to subsume the Comment controller into the Post controller. I only decided this after having tried separate controllers, however. I think this worked because the two concepts are so tightly entwined: you can't have a comment without a blog post.

Answer 3

My approach is to create a new controller for the primary actors (tables) in the system. Ancillary tables end up begin updated by the controller for the primary table that the ancillary data is associated with. For example, I would have a User controller and have an action to update the UserContact information that is associated with a particular user in the User controller rather than create a separate UserContact controller.

Answer 4

I find the bets way is to once you get to the presentation layer (web layer in this case) you should group logically rather then technically. If you have a Product and Category table you may want to make a Catalog controller, or a Store controller. This will help and allow you to reuse a lot of code and keep things organized.