Pourquoi tout le monde place les contrôleurs dans un dossier et les vues dans un autre?
Je me prépare à prendre le virage de asp et dans un framework mvc, asp.net mvc ou nancy. Partout où je vais, je vois des dossiers pour les contrôleurs/modules et des dossiers pour les vues. Est-ce juste un réflexe pavlovien de ranger les choses par type, ou existe-t-il une sagesse plus profonde? J'ai un petit projet de preuve de concept où je stocke ensemble les fichiers que je suis susceptible d'ouvrir ensemble, un confort considérable. Étant donné que ces fichiers sont également susceptibles de s'appeler, ils peuvent le faire avec des liens relatifs plus courts et moins fragiles. Ce modèle est contesté par mvc, car le chemin du dossier ne correspond plus automatiquement au chemin de l'url et, dans asp.net mvc, les modèles de projet et le routage appliquent les vues\contrôleurs\schisme.
Cette page Microsoft introduit le concept de zones. Il peut être lu comme un aveu de la complexité des applications volumineuses à cause de cette séparation artificielle.
Les gens s'opposeront à la "séparation des préoccupations", mais la séparation des préoccupations est déjà réalisée en ayant des fichiers sources séparés. Il n'y a aucun gain concret, me semble-t-il, à prendre ces fichiers sources qui sont étroitement couplés et à les envoyer aux extrémités opposées de la structure des dossiers?
Quelqu'un d'autre se bat-il contre cela? Des conseils?
Je voudrais dire que c'est programmation culte du fret , mais il y a des raisons techniques pour cette structure. Asp.Net MVC a adopté une convention sur l'approche de configuration pour presque tout. Par défaut, le moteur de vue Razor recherche dans le répertoire Views afin de déterminer quelle vue retourner depuis le contrôleur. Il y a cependant quelques hacks pour obtenir une structure de projet différente et Microsoft fournit même une fonctionnalité MVC appelée Areas pour nous permettre de créer une structure de projet plus saine. Vous pouvez également implémenter votre propre moteur de vue afin de spécifier où chercher les vues.
Pourquoi dois-je dire que c'est une programmation culte du fret et que vous avez raison à ce sujet? Oncle Bob m'a convainc que la structure du répertoire du projet ne devrait pas me dire qu'il s'agit d'une application MVC. Cela devrait me dire que c'est une vitrine, ou un système de demande de congé, ou autre chose. La structure et l'architecture de haut niveau devraient nous dire ce qu'est cette chose, pas comment il a été mis en œuvre.
En bref, je pense que vous avez raison à ce sujet, mais toute autre structure de répertoires lutterait simplement contre le cadre et croyez-moi quand je dis que vous ne voulez pas essayer de faire le cadre MVC Asp.Net faire quelque chose qu'il n'était pas pas conçu pour faire. Dommage que ce ne soit pas vraiment plus configurable.
Pour répondre rapidement aux préoccupations architecturales, je pense toujours que les modèles commerciaux (entreprise, pas de vue) et le DAL doivent vivre dans un projet/bibliothèque distinct qui est appelé depuis votre application MVC.
C'est juste que le contrôleur est vraiment très étroitement couplé à la vue et susceptible d'être modifié ensemble. Nous sommes tous sages de nous rappeler la différence entre le couplage via la dépendance et le couplage logique. Ce n'est pas parce que le code a vu ses dépendances découplées qu'il est moins logiquement couplé.
Quelle que soit la raison, c'est une mauvaise pratique. C'est très anti-OO car les packages ou les dossiers (quel que soit le nom que vous voulez les utiliser), devraient avoir de faibles interdépendances. Les classes (ou fichiers) à l'intérieur doivent avoir de fortes interdépendances.
En lançant toutes les vues dans un dossier et tous les contrôleurs dans un autre dossier, vous créez deux packages avec un couplage très très serré. Cela va à l'encontre du principe d'avoir de faibles dépendances inter-packages.
Une vue et un contrôleur sont les deux moitiés d'un tout et doivent appartenir l'un à l'autre. Vous n'auriez pas un tirage placard pour les chaussettes côté gauche, et un autre tirage pour les chaussettes côté droit.
Pour répondre à votre "Pourquoi tout le monde ...?" question: Voici quelques raisons potentielles, bien que je ne sois pas tout à fait sûr quelle combinaison d'entre elles est une cause réelle, car il s'agit en fait d'une question subjective
Pour répliquer l'architecture logique (modèle, vue, contrôleur) avec un dossier et une structure d'espace de noms correspondants
Par convention et commodité pour suivre le modèle de projet ASP.net MVC
Pour regrouper par espace de noms, puisque
Controllers/le dossier mènera à un.Controllersespace de nomsMight activer certains scénarios en DI/IoC où les classes de contrôleurs sont uniquement interrogées/analysées à partir d'un espace de noms qui contient/se termine par des `` contrôleurs '' (cela pourrait être faux)
Pour permettre aux modèles T4 de numériser et aux modèles d'échafaudage et aux contrôleurs de générer des vues
Vous pouvez toujours créer et suivre votre propre convention si cela a du sens pour votre projet, personne ne peut/ne vous arrêtera. Mais gardez à l'esprit que si vous travaillez dans un grand projet et/ou une grande équipe, la convention par défaut connue de tous pourrait être un meilleur choix (pas nécessairement la bonne, cependant!)
Si votre convention est plus facile à suivre et n'entrave pas la productivité, alors faites-le par tous les moyens! et peut-être même écrire à ce sujet un ou deux articles de blog pour le socialiser avec la communauté des développeurs et obtenir des commentaires
L'une des raisons de conserver les vues et les contrôleurs dans des répertoires distincts est lorsque des développeurs frontaux et principaux travaillent sur un projet. Vous pouvez empêcher les développeurs frontaux d'accéder au code backend (par exemple pour aider à la conformité PCI, restreindre qui a accès au code sensible).
Une autre raison est de rendre plus facile d'avoir des "thèmes" et de désactiver tous des modèles en apportant une modification mineure au chemin d'affichage.
Une troisième raison est d'avoir un modèle de répertoire simple lors de la spécification des vues dans le framework MVC. Il est plus facile de spécifier le sous-répertoire et le fichier plutôt qu'un grand chemin long vers chaque vue.
Le seul "couplage serré" devrait être:
- Variables envoyées dans la vue par le contrôleur.
- Champs de formulaire ou actions dans la vue, renvoyés au contrôleur.
J'utilise un contrôleur générique et j'essaie de conserver les noms de variables dans la vue générique, de sorte que de nombreuses vues puissent utiliser le même contrôleur et que de nombreux contrôleurs puissent utiliser la même vue. Pour cette raison, je préfère garder les vues complètement séparées. Le modèle est l'endroit où vous pouvez différencier chaque "chose" dans votre application - il peut s'agir d'objets avec une liste de propriétés et de méthodes pour accéder/modifier ces propriétés.
Pour le code étroitement couplé, une approche qui pourrait fonctionner pour vous consiste à conserver tous les fichiers qui font partie d'un package ou d'un "module" ensemble dans un répertoire à espace de noms. Ensuite, vous pouvez utiliser un script pour copier ou "compiler" vos modèles bruts dans le répertoire principal "vues". Par exemple:
lib/my-namespace/my-package/
-> controllers/
-> models/
-> views/
-> theme/
-> template-name1
app/compiled_views/theme/
-> url/path/template-name1
Malheureusement, si vous souhaitez modifier la structure d'un thème existant, il y a plus de tissage dans et hors des répertoires de packages pour mettre à jour les vues.
Considérez que les vues ne sont qu'un moyen de formater les données, que ce soit json, xml, csv ou html. Cela est particulièrement utile si vous souhaitez que votre application fonctionne également comme une API. Essayez de découpler la vue des données, en utilisant des noms de variables génériques, afin que vous puissiez utiliser le même modèle pour de nombreux contrôleurs ou modèles (ou utilisez des inclusions pour minimiser la quantité de code que vous devez conserver).
N'oubliez pas que c'est la méthode recommandée par Microsoft pour conserver les contrôleurs et les vues dans des dossiers différents, donc beaucoup suivraient la structure recommandée,
- Une des raisons pourrait être que les contrôleurs n'ont toujours pas de relation un à un avec les vues, en particulier les vues partielles peuvent être partagées entre les contrôleurs.
- Une autre raison pourrait être lorsque votre projet se développe, vous voudrez peut-être retirer les contrôleurs et les tests unitaires vers un autre projet, mais il est assez difficile de faire de même pour les vues plus les vues/js/css appartiennent ensemble car elles se réfèrent.
Cela dit, il existe de nombreux articles sur la façon de le faire à votre façon, tels que this .
Pas nécessairement tout le monde le fait. Par exemple, le framework Django de python a le concept d'une application, où les sous-modules de votre application vivent dans leurs propres répertoires avec leurs propres modèles et vues et modèles (les vues sont ce qui Django appelle essentiellement les contrôleurs.) Il se trouve que je préfère cette façon de faire les choses, car cela signifie que je peux facilement empaqueter une "application" et la réutiliser dans tous les projets simplement en l'incluant dans la liste des applications dans les paramètres de mes projets. aussi plus facile de découvrir où se trouvent les différentes parties. Si je regarde le fichier urls.py et que je vois quelque chose comme url(r'^users/', include('my_site.users.urls')), je sais que le module my_site.users contient tout le code qui gère les utilisateurs. Je sais regarder les modules my_site.users.views et my_site.users.models quand je veux voir comment les utilisateurs sont créés et authentifiés. Je sais que tous mes itinéraires sont définis dans my_site.users.url.
De plus, s'il est suffisamment générique, je peux probablement utiliser ce module dans d'autres sites simplement en changeant la configuration ou en l'empaquetant comme bibliothèque et en le publiant en tant qu'OSS.
Pour mémoire
Pourquoi dois-je dire que c'est une programmation culte du fret et que vous avez raison à ce sujet? L'oncle Bob m'a convaincu que la structure de répertoires du projet ne devrait pas me dire qu'il s'agit d'une application MVC. Cela devrait me dire que c'est une vitrine, ou un système de demande de congé, ou autre chose. La structure et l'architecture de haut niveau devraient nous dire ce qu'est cette chose, pas comment elle a été mise en œuvre.
Question: Qui a accès au code?. Programmeurs. Les utilisateurs finaux se soucient-ils du code?. Et ce que fait un programmeur, du code. Ou plus précisément, des classes basées sur des types (contrôleurs, service, modèle, etc.). Il est donc logique et il est facile de déboguer un code, si vous êtes en mesure de trouver un code basé sur le type de code, plutôt que dans le comportement du code. De plus, disons un projet d'équipe, l'un est en charge du contrôleur, un autre du modèle, un autre du dao et un autre de la vue. Il est facile de séparer le projet en plusieurs parties. Un bon code est un code facile à déboguer, pas un code de sucre de syntaxe. L'oncle Bob a encore tort.
Essayer d'imiter le comportement du projet (une devanture de magasin) est un culte du fret.