Les contrôleurs sont généralement créés pour une certaine ressource (une classe d'entité, une table dans la base de données), mais peuvent également être créés pour regrouper des actions responsables d'une certaine partie de l'application. Dans vos exemples, ce serait un contrôleur qui gère la sécurité de l'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();
}
Remarque : ne placez pas les actions liées à la sécurité et les actions de profil utilisateur dans le même contrôleur; cela peut avoir un sens car ils sont liés à l'utilisateur, mais l'un doit gérer l'authentification et l'autre doit gérer les e-mails, les noms, etc.
Avec des contrôleurs créés pour les ressources (disons Task), vous auriez les actions CRUD habituelles :
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()
}
Bien sûr, vous avez la possibilité d'ajouter des ressources associées au même contrôleur. Disons par exemple que vous avez l'entité Businesset que chacune a plusieurs BusinessServiceentités. Un contrôleur pour cela pourrait ressembler à ceci:
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);
}
Cette approche est logique lorsque les entités enfants liées ne peuvent pas exister sans l'entité parent.
Voici mes recommandations:
- créer des contrôleurs basés sur un groupe d'opérations connexes (gérer certaines responsabilités comme la sécurité ou les opérations CRUD sur les ressources, etc.);
- pour les contrôleurs basés sur les ressources, n'ajoutez pas d'actions inutiles (si vous n'êtes pas censé mettre à jour la ressource, n'ajoutez pas l'action de mise à jour);
- vous pouvez ajouter des actions "personnalisées" pour simplifier les choses (par exemple, vous avez une
Subscriptionentité qui a une disponibilité basée sur un nombre limité d'entrées, vous pouvez ajouter une nouvelle action au contrôleur nommé use()qui a pour seul but de soustraire une entrée de la Subscription)
- garder les choses simples - n'encombrez pas votre contrôleur avec un grand nombre d'actions et une logique complexe, essayez de simplifier les choses en diminuant le nombre d'actions ou en créant deux contrôleurs;
- si vous utilisez un framework axé sur MVC, suivez leurs recommandations de bonnes pratiques (si elles l'ont).
Quelques ressources à lire ici .