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:
- L'utilisateur se connecte.
- 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.
Réponses:
Pour votre exemple, je créerais deux contrôleurs:
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.
la source
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.
la source
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:
la source
J'aime la façon dont Apple le fait.
L'idée est que vous devriez pouvoir échanger facilement des vues. OMI, en ayant seulement 1
ControllerparViewil 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.la source
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!
la source
Je suppose que votre exemple évoluera vers un système complexe.
Application:
L'utilisateur se connecte:
LoginControllerSa seule responsabilité est de gérer les connexions, de rediriger ou d’informer l’utilisateur du résultat.
Télécharger un fichier
UploadControllerJe 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.
SearchFileControllerCela 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
LoginControlleretLogoutControllerdans une zone séparée.J'ai déjà développé quelque chose comme ça et ça a très bien fonctionné.
la source
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.
la source
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
la source