Controllers are usually created for a certain resource (an entity class, a table in the database), but can also be created to group together actions that are responsible with a certain part of the application. In your examples, that would be a a controller that handles the security for the application:
class SecurityController
{
// can handle both the login page display and
// the login page submission
login();
logout();
register();
// optional: confirm account after registration
confirm();
// displays the forgot password page
forgotPassword();
// displays the reset password page
// and handle the form submission
resetPassword();
}
Note: don't put the security related actions and the user profile actions in the same controller; it might make sense because they are related to the user, but one should handle authentication and the other should handle email, name etc. updates.
With controllers created for resources(let's say Task), you would have the usual CRUD actions:
class TasksController
{
// usually displays a paginated list of tasks
index();
// displays a certain task, based on an identifier
show(id);
// displays page with form and
// handles form submission for creating
// new tasks
create();
// same as create(), but for changing records
update(id);
// displays confirmation message
// and handles submissions in case of confirmation
delete()
}
Of course, you have the possibility to add related resources to the same controller. Say for example you have the entity Business, and each one has several BusinessService entities.
A controller for it might look like this:
class BusinessController
{
index();
show(id);
create();
update(id);
delete();
// display the business services for a certain business
listBusinessServices(businessId);
// displays a certain business service
showBusinessService(id);
// create a new business service for a certain business
createBusinessService(businessId);
// updates a certain business service
updateBusinessService(id);
// deletes a certain business service
deleteBusinessService(id);
}
This approach makes sense when the related children entities cannot exists without the parent entity.
These are my recommendations:
- create controllers based on a group of related operations (handling certain responsibilities like security, or CRUD operations on resources etc.);
- for resource-based controllers, don't add unnecessary actions (if you are not supposed to update the resource, don't add the update action);
- you can add "custom" actions to simplify things (e.g. you have a
Subscription entity that has an availability based on a limited number of entries, you can add a new action to the controller named use() that has the single purpose of subtracting one entry from the Subscription)
- keep things simple - don't clutter your controller with a huge number of actions and complex logic, try to simplify things by decreasing the number of actions or making two controller;
- if you are using an MVC focused framework, follow their best-practice guidelines (if they have it).
Some resources for further reading here.
