What Defines the Traditional "Page" Concept in MVC?

Question

I currently use CodeIgniter as my framework of choice when using PHP. One of the things I am wrestling with is the idea of a "page", and how to represent that properly within MVC. To my knowledge, CodeIgniter has a front controller that delegates to page controllers. In my thought process, each page would have it's own controller. All too often though I see someone using a page controller stuffed with many methods. So in that sense, each action becomes it's own page.

I've never really liked the idea of stuffing many methods into one controller, because it seems like there will be too much overhead if you only need one method or two in the controller at a time. It's seems more reasonable for each page to have it's own controller, and the actions would only correspond to something you can do on that particular page. Am I thinking about this the wrong way?

What makes it more confusing is I'll notice in some web applications where they will have one controller that will have multiple methods (i.e. login, register, view, edit, etc.), but then on others they actually have a login controller, and a register controller. What is the proper use of a "page controller"?

Answer 1

From a domain perspective I definitely say it makes more sense to have 1 controller per domain context. Not necessarily one per page although depending on the context this may be the case. What I mean by context is "actions that are closely related".

For instance an account controller should handle the login, register, logout, change password, actions. They all live within the context of an "Account"

Take Stackoverflow for example. I would have a "Questions" controller which would have actions like DisplayQuestion, AskQuestion, Delete Question, MostRecent Questions, etc. They are all different "Views/pages" that are managed by one controller.

Answer 2

You're right in that every public method in a controller becomes a "page". That being said, it's not necessarily a web page, an action could be a post of data and then redirect to another action/page so page does not necessarily mean "web page".

MVC uses a lot of conventions to make things work. For instance, every controller must end with "Controller". So a set of user pages (create, edit, delete, etc.) would be in a UserController. In the Views folder, each public method or action within the controller class becomes a web page within a folder that matches the prefix of the controller (In this case, a User folder). So an action called "Delete" within the controller class would point to the Delete.aspx page within the User folder.

It seems a little awkward to put all of those methods in one class, but it does a nice job of organizing like functionalities based on your object.

Answer 3

In MVC, a 'page' is what you get when you put the three together. The model handles the data layer, the view handles the actual HTML the user sees and the controller decides how they interface together to show the desired data. My choice as to use a separate controller or another method to an existing controller hinges on how close the operation is to the other controller(s) that I have. Say I wanted to have a UserAdmin controller, now that would most-likely handle adding a user, deleting a user, changing passwords, etc. If I was adding functionality that dealt with changing a user's account in some way I would most likely put it in there. If I had separated them out into their own controller's I would naturally add another one. Controllers allow you to house similar tasks together so they may leverage what is already in the class, rather than having to recreate what has already been done. A lot of it is how the programmer thinks it should be done. What makes sense to you may not make sense to me, that is the developer's (or the designer's) choice.