Architecture MVC - De combien de contrôleurs ai-je besoin?
Je code depuis un certain temps, mais surtout des scripts et des applications simples. Je suis passé à un nouveau rôle où il s'agit de développer des applications Web et d'utiliser une architecture MVC appropriée, donc j'essaie désespérément d'en savoir très rapidement.
J'espère que cette question n'est pas trop similaire à " Meilleures pratiques pour l'architecture MVC " mais en parcourant quelques tutoriels différents, j'ai remarqué que certains ont plusieurs contrôleurs pour différentes choses.
De combien de contrôleurs une seule application Web a-t-elle besoin?
Je me rends compte qu'il serait difficile de répondre sans un exemple, je vais donc en fournir un:
Application:
- L'utilisateur se connecte.
- L'utilisateur peut effectuer trois opérations:
a) Téléchargez un fichier (stocké dans une base de données mongodb avec des métadonnées).
b) Recherchez un fichier.
c) Déconnectez-vous.
Ma question est générale, mais j'ai donné l'exemple pour aider quiconque essaie de répondre.
Pour votre exemple, je créerais deux contrôleurs:
- Contrôleur de sessions pour la connexion et la déconnexion (créer et détruire une session pour REST comme la disposition)
- Contrôleur de fichiers pour tout sur les fichiers (index = rechercher et créer = télécharger)
En général, une approche RESTful où vous pensez à tout comme une ressource qui peut être affichée, créée, modifiée et détruite vous donne une bonne idée de la façon de structurer les choses. Comme vous pouvez le voir dans mes exemples, je ne m'en tiens pas trop près de chaque verbe dans REST.
Vous auriez probablement besoin de plus de contrôleurs pour plus de fonctionnalités. Par exemple, un contrôleur d'utilisateurs où les utilisateurs peuvent créer de nouveaux comptes. Et en plus de cela, vous auriez besoin d'une interface d'administration où vous pouvez modifier les ressources avec des privilèges plus élevés. Dans un tel cas, il est assez courant d'avoir presque tous les contrôleurs dupliqués.
Une estimation très très approximative pour avoir une idée initiale pourrait être un contrôleur pour chaque table de votre base de données à laquelle les utilisateurs peuvent accéder. Mais ce n'est vraiment qu'une mesure très grossière.
Cela dépend vraiment de l'application Web. Dans votre exemple, un est probablement suffisant. Si vous deviez mettre en œuvre une application de commerce électronique complète avec expédition, taxes, gestion des stocks, tarification à plusieurs niveaux, etc., alors vous voudrez peut-être en avoir quelques autres.
Si votre contrôleur souffre d'un ou plusieurs le code sent (en particulier Grande classe ou objet divin ) alors vous savez que vous avez probablement dépassé le point où un seul suffira.
Cela dépend vraiment des besoins de votre application et de l'architecture des modules métier.
Une règle générale , le nombre de contrôleurs requis dépend d'un certain nombre de modules et sous-modules dans l'application Web.
En complément, il serait utile d'organiser les contrôleurs en zones . Le concept de Areas est intégré dans le framework ASP.NET MVC et simplifie l'organisation des contrôleurs qui desservent un module.
Il y a un certain nombre de discussions connexes:
J'aime la façon dont Apple le fait.
Chaque vue est contrôlée par un seul contrôleur de vue. ~ Afficher le guide de programmation du contrôleur pour iOS
L'idée est que vous devriez pouvoir échanger facilement les vues. OMI, en ayant seulement 1 Controller par View, il est plus facile d'accomplir cela. Mais je suis sûr que vous pourriez avoir un contrôleur avec plusieurs vues et le concevoir afin que vous puissiez changer de vue sans changer la logique du programme.
Un exemple que j'aime est de penser à un thermostat. Un thermostat est un excellent visuel pour visualiser le modèle MVC.
Sur un thermostat analogique plus ancien, vous pouvez imaginer des choses comme ceci:
Afficher - Le lecteur de température, qui affiche la température actuelle.
Controller - Le cadran, où vous modifiez la température
Modèle - Les pièces à l'intérieur qui sont invoquées par le contrôleur et qui font changer la température.
Vous devez toujours respecter les conceptions qui permettent un couplage lâche et des modèles de limite et leurs contrôleurs associés à une seule tâche, et vous devez utiliser autant de modules/contrôleurs que nécessaire . Selon la taille de votre application, vous pouvez avoir beaucoup moins de vues que les modèles et contrôleurs. Cela est normal avec toute application de grande taille. Une bonne programmation orientée objet se caractérise par un couplage, une encapsulation, un héritage et un polymorphisme lâches. Tous les langages ne prennent pas en charge le polymorphisme au même degré (fonction, méthode, surcharge/surcharge de l'opérateur).
Si vous voulez avoir une meilleure compréhension de l'utilisation correcte de l'architecture MVC, consultez le GoF "Design Patterns: Elements of Reusable ... Software" qui utilise C++ et Smalltalk par exemple du code. Ce livre n'est pas l'alpha et l'oméga, mais c'est certainement un début!
Bonne chance!
Je suppose que votre exemple évoluera vers un système complexe.
Application:
L'utilisateur se connecte:
LoginController
Sa seule responsabilité est de gérer les connexions, de rediriger ou d'informer l'utilisateur du résultat.
Télécharger un fichier
UploadController
Je suppose ici que vous souhaitez télécharger tout type de fichier. Si, à une date ultérieure, vous décidez de télécharger des fichiers MP3 et PDF, j'aurais alors un UploadController de base, MP3UploadController et PDFUploadController.
Rechercher un fichier.
SearchFileController
Cela suffirait pour une exigence de base. Vous pouvez avoir plusieurs contrôleurs de recherche à une date ultérieure selon la complexité de la logique de recherche. La dernière chose que vous voulez avoir est un seul SearchController avec 20 méthodes d'action effectuant des recherches différentes.
Se déconnecter.
- LogoutController.
On pourrait considérer cela comme une exagération, mais je ne pense pas que ce soit le cas. Je pense que c'est propre et bien séparé.
Si je regardais cette structure de projet, je saurais instantanément ce qu'elle fait et comment elle est structurée. Pour aller plus loin, je mettrais LoginController et LogoutController dans une zone distincte.
J'ai développé quelque chose comme ça avant et cela a très bien fonctionné.
La plupart de votre code se produirait dans une couche métier, n'est-ce pas? Si tel est le cas, tout ce que vous faites réellement dans votre contrôleur est de retourner des données à la vue.
Je ne sais pas vraiment si je suis un fan de la séparation des contrôleurs en sous-types. Alors que vous devez maintenir la séparation des préoccupations, je pense que les sous-types vont un peu trop loin. Vous devez également faire attention dans les cas où des objets lourds sont initialisés dans le constructeur ou un contrôleur. Par exemple: dans votre exemple, vous voudriez qu'un objet lourd, utilisé uniquement pour le fichier de recherche/téléchargement soit publié lorsque l'utilisateur est sur la page de connexion.
Il est préférable d'avoir un contrôleur par unité logique, par exemple AccountController (connexion, enregistrement, déconnexion), FileController (recherche, téléchargement) et ainsi de suite.
En général, vous pouvez dire que chaque MODÈLE a ses propres CONTRÔLEURS et VUES dédiées. En disant général, je veux dire que c'est la meilleure pratique.
les aspects d'application (comme la gestion des utilisateurs) doivent être traduits en service d'application et doivent être appelés par le contrôleur lui-même, ou pour envelopper votre contrôleur (en utilisant des attributs qui rendent la fonctionnalité du contrôleur "visible" en fonction du rôle d'utilisateur de la demande, par exemple).
N'oubliez pas que tous les contrôleurs doivent essentiellement gérer les opérations CRUD sur le modèle et utiliser différentes vues pour différents filtres.
À mon avis, l'un des principaux avantages de MVC en tant que modèle est qu'il offre le meilleur moyen de lier des modèles et des vues.
À propos de l'exemple que vous avez ajouté: Je créerais 2 contrôleurs: un pour l'opération de connexion de tous les utilisateurs (enregistrement, connexion, déconnexion, etc.) et le second pour les opérations de fichiers (téléchargement et recherche). notez que le premier doit également être sauvegardé avec certains aspects liés à la fonctionnalité de connexion et le second est un contrôleur ordinaire