Architecture MVC - De combien de contrôleurs ai-je besoin?

Je code depuis un moment, mais principalement des scripts et des applications simples. J'ai changé de rôle et je me suis donné pour mission de développer des applications Web et d'utiliser une architecture MVC appropriée. J'essaie donc désespérément de découvrir tout cela très rapidement.

J'espère que cette question ne ressemble pas trop aux " Meilleures pratiques pour l'architecture MVC ", mais alors que je suis en train de parcourir quelques tutoriels différents, j'ai remarqué que certains avaient plusieurs contrôleurs pour différentes choses.

De combien de contrôleurs une seule application Web a-t-elle besoin?

Je me rends compte que ce serait difficile de répondre sans exemple, alors je vais vous en donner un:

Application:

1. L'utilisateur se connecte.
2. L'utilisateur peut faire l'une des trois choses suivantes:
   a) Télécharger 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 d'ordre général, mais j'ai donné l'exemple pour aider ceux qui essaient 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 une présentation)
• Contrôleur de fichiers pour tout ce qui est sur les fichiers (index = rechercher et créer = télécharger)

En général, une approche RESTful dans laquelle vous pensez à tout comme une ressource pouvant être affichée, créée, modifiée et détruite vous donne une bonne idée de la structure à adopter. Comme vous pouvez le constater à partir de mes exemples, je ne colle pas trop près de chaque verbe dans REST.

Vous aurez 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 aurez besoin d'une interface d'administration où vous pouvez éditer les ressources avec des privilèges plus élevés. Dans un tel cas, il est assez courant de faire dupliquer presque tous les contrôleurs.

Une idée très approximative pour avoir une idée initiale pourrait être un contrôleur pour chaque table de votre base de données accessible aux utilisateurs. Mais ce n’est vraiment qu’une mesure très grossière.

Cela dépend vraiment de l'application Web. Dans votre exemple, un suffit probablement. Si vous deviez mettre en œuvre une application de commerce électronique complète avec expédition, taxes, gestion des stocks, tarification différenciée, etc., vous voudrez peut-être en avoir plusieurs autres.

Si votre contrôleur souffre d'une ou de plusieurs odeurs de code (en particulier de grande classe ou d'objet divin ), vous savez que vous avez probablement dépassé le point où vous n'en aurez plus qu'une.

Cela dépend vraiment des besoins de votre application et de l'architecture des modules métier.

En règle générale , le nombre de contrôleurs requis dépend d'un nombre de modules et de sous-modules dans l'application Web.

En complément, il serait utile d’organiser les contrôleurs en zones . Le concept de zones est intégré à l'infrastructure ASP.NET MVC et simplifie l'organisation des contrôleurs desservant un module.

Il y a un certain nombre de discussions connexes:

• Architecture MVC
• Conception des actions du contrôleur ASP.NET MVC
• mvc Controller And Voir l'organisation des annuaires
• À quoi ressemble l'organisation de classe MVC pour plusieurs vues et contrôleurs?

J'aime la façon dont Apple le fait.

Chaque vue est contrôlée par un seul contrôleur de vue. ~ Voir le Guide de programmation du contrôleur pour iOS

L'idée est que vous devriez pouvoir échanger facilement des vues. OMI, en ayant seulement 1 Controllerpar Viewil le rend plus facile à accomplir. Mais je suis sûr que vous pourriez avoir un contrôleur avec plusieurs vues et le concevoir de manière à pouvoir changer de vue sans changer la logique du programme.

Un exemple que j'aime bien pense à 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:

View - Le lecteur de température, qui affiche la température actuelle.

Contrôleur - Le cadran, où vous modifiez la température

Modèle - Les pièces internes invoquées par le contrôleur qui entraînent un changement de température.

Vous devez toujours respecter les conceptions qui permettent un couplage lâche, limiter les modèles et leurs contrôleurs associés à une tâche unique , et utiliser autant de modules / contrôleurs que nécessaire . En fonction de la taille de votre application, vous pouvez avoir beaucoup moins de vues que les modèles et les contrôleurs. Ceci est à prévoir avec n'importe quelle application de grande taille. Une bonne programmation orientée objet est caractérisée par un couplage lâche, une encapsulation, un héritage et un polymorphisme. Toutes les langues ne prennent pas en charge le polymorphisme au même degré (fonction, méthode, surcharge de l'opérateur).

Si vous souhaitez mieux comprendre comment utiliser correctement l'architecture MVC, consultez le document GoF "Modèles de conception: éléments d'un logiciel réutilisable ..." qui utilise le code C ++ et SmallTalk, par exemple. 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 voulez télécharger n'importe quel type de fichier. Si, à une date ultérieure, vous décidez de télécharger des fichiers MP3 et PDF, vous disposez alors des bases UploadController, MP3UploadController et PDFUploadController.

Rechercher un fichier.

• SearchFileController

Cela suffirait pour une exigence de base. Vous pouvez avoir plusieurs contrôleurs de recherche ultérieurement, en fonction de la complexité de la logique de recherche. La dernière chose que vous souhaitez avoir est un seul SearchController avec 20 méthodes d’action qui effectuent différentes recherches.

Se déconnecter.

-LogoutController .

On pourrait considérer cela comme une exagération, mais je ne le pense pas. Je pense que c'est propre et bien séparé.

Si je regardais cette structure de projet, je saurais instantanément ce qu'il fait et comment il est structuré. Pour aller un peu plus loin, je mettrais LoginControlleret LogoutControllerdans une zone séparée.

J'ai déjà développé quelque chose comme ça et ça a très bien fonctionné.

La plupart de votre code se passerait 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 renvoie les données à la vue.

Pas vraiment sûr si je suis fan de séparer les contrôleurs en sous-types. Bien que vous devriez maintenir une séparation des préoccupations, je pense que les sous-types vont un peu trop loin. Vous devez également faire attention lorsque 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 la recherche / le téléchargement du fichier, 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), etc.

En général, vous pouvez dire que chaque modèle a ses propres contrôleurs et vues dédiées. En général, je veux dire que c’est la meilleure pratique.

Les aspects de l'application (tels que 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 encapsuler votre contrôleur (en utilisant des attributs qui rendent la fonctionnalité du contrôleur "visible" en fonction du rôle d'utilisateur de la requête, par exemple).

N'oubliez pas que tous les contrôleurs doivent en principe 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 sur les fichiers (téléchargement et recherche). notez que le premier doit également être sauvegardé avec un aspect lié à la fonctionnalité de connexion et le second est un contrôleur ordinaire