How do I determine my controllers in MVC?

Question

Hello,

I'm fairly new to MVC coming from a php background where I designed by view and created pages when I needed something like say a login form. I'd have a file called login. This only sucked when I needed a new login form to login a different type of user. Say an admin. I'd then have to create a new page called login-admin.php or something of that nature.

Recently I began to explore MVC and particularly frameworks and the biggest problem I am having is determining how exactly you come up with your controllers. I've been told to either go the one controller per view file route, or get your controllers based upon your domain objects.

I understand I can have a user controller and a lot of methods to manipulate that object say user/add, user/edit, user/delete, user/profile. But in this instance it seems that once you need views that don't necessarily fit within a "domain object" that it's hard to decide where to stick them.

So, what is the best practice when determining what your controllers will be???

Answer 1

I use one controller per "area of concern".. That's sort of arbitrary, and generally is a slightly larger category, based in the domain model, that includes multiple objects.

In other words, lets say in your domain model you have security as one of your areas of concern. It might involve many views, and many domain objects, but I would make it a single controller, which handled all security related actions.

Answer 2

With Ruby on Rails (and more other MVC web frameworks), controllers are mapped to URL's via some kind of routing config.

For example, /mysection/view/2 is generally mapped to controller = mysection, method = view, id = 2 (in Rails, that's the default mapping, in ./config/routes.rb: map.connect ':controller/:action/:id')

When you say you have "a user controller and a lot of methods to manipulate that object say user/add, user/edit, user/delete, user/profile", I think you mean a model - so you would have UserModel.create(), UserModel.find() etc.. The controller would then use the model to edit the data - the actual controller should only have a few lines of code calling the model (say @myuser = User.find(id)), and a few methods that are mapped to URLs (say /usercontroller/new, /usercontroller/edit, /usercontroller/view)

That description was fairly Rails-specific, but most of the PHP frameworks will be pretty similar - I know CodeIgniter uses pretty much the same layout.

Answer 3

Controllers are more like a section of code from where invocations are triggered. In a well encapsulated code, the methods that modify the model are present close to the model (in the same domain object). The invocation point is however is seperated (not part of the same domain object).

Some frameworks like struts, provide controllers that are configurable (using xml). There is also a concept of Front Controller, where a generic controller acts as a top level delegator. We can use this front controller to handle trivial mappings (not strictly dealing with domain).

Answer 4

When creating controllers, I usually think about what the user sees, and what would be intuitive for the user, since controllers are mapped onto URLs.

In your example, it makes sense to have all user-related pages to have the format /user/edit, /user/profile etc. as you said. However, if I were you I would not have a separate login page for admins, I would use the same login view, and handle the admin bit elsewhere.

In short, generally I make a controller for each key concept that the user will have in mind when they are using the site. So if users on the site could add/remove friends, I would think of that as a concept on its own (rather than being a part of the user concept). So I would have a friends controller, with functionality such as friends/add, friends/list, friends/remove etc.