Que devriez-vous nommer votre contrôleur dans MVC? Quand devriez-vous en créer un nouveau?

Question

J'ai une question qui s'applique vraiment à n'importe quel framework MVC, j'utilise le Zend Framework MVC.

Quand devriez-vous créer un nouveau contrôleur? Que devrait exactement définir la couche Controller?

J'ai créé plusieurs applications avec le MVC, devenant progressivement plus réutilisable, mais j'ai toujours eu du mal à nommer les classes Controller. Pour la plupart, il correspond à toutes les demandes d'URL, donc la logique métier/front-end. Mais dans certains cas, cela semble totalement arbitraire.

Est-ce que quelqu'un a des heuristiques/lignes directrices à suivre? On dirait qu'avec tout le battage médiatique autour de MVC, en particulier avec PHP, il y a peu de données sur les conventions et les heuristiques. Comme il est assez facile de créer une application MVC désorganisée ...

Answer 1

J'ai généralement un contrôleur pour chaque groupe logique de fonctions. Souvent, cela correspondra à un contrôleur par modèle, parfois non. Imaginez que vous créez un catalogue en ligne simple qui affiche une liste de catégories, puis lorsque l'utilisateur sélectionne une catégorie, affiche une liste de produits de cette catégorie, ainsi qu'un panneau d'administration pour les catégories et les produits CRUD. J'aurais deux modèles (CategoryModel et ProductModel). J'aurais un contrôleur qui a généré les listes de catégories pour le frontal, et un autre contrôleur qui a généré les listes de produits (par exemple, CategoryController et ProductController). J'aurais alors un contrôleur pour les catégories et les produits sur le dos (AdminCategoryController et AdminProductController). Les deux contrôleurs principaux géreraient les opérations list/add/edit/delete/view pour leurs modèles respectifs. Si vous pensez à la structure de votre URL et que vous placez des fonctions connexes sur les URLs associées, la structure de votre contrôleur correspondra souvent à la structure de votre URL. En fait, certains cadres (par exemple CodeIgniter) acheminent les demandes en fonction du nom du contrôleur en tant que comportement par défaut. En ce qui concerne ce qui se passe dans les contrôleurs, je travaille dans l'idée que les modèles sont pour l'accès aux données, et enveloppent et cachent la structure de la base de données. Une logique telle que "affecter l'heure actuelle à completion_date lorsque l'état est défini sur" complete "est un bon ajustement des modèles.

Les vues contiennent l'intégralité de votre présentation. Les contrôleurs/modèles ne doivent pas générer ou gérer du code HTML. Les décisions telles que 2 colonnes ou 3 appartiennent aux vues. La logique dans les vues doit être restreinte à celle qui est requise pour générer la sortie visible. Si vous souhaitez interroger la base de données à partir d'une vue, vous mettez probablement trop de logique dans la vue.

Les contrôleurs sont pour ce qui reste. Généralement, cela signifie, valider l'entrée, affecter des données de formulaire aux modèles, sélectionner les bonnes vues et instancier les modèles requis pour gérer la requête.

Answer 2

Pour l'essentiel, je suis le modèle de contrôleur par modèle. J'ai quelques contrôleurs qui peuvent servir plusieurs modèles (comme le contrôleur d'administration qui sert plusieurs modèles administratifs), mais la règle générale est un contrôleur par modèle d'affaires.