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 consistant à ranger les choses par type, ou y a-t-il une sagesse plus profonde qui opère? J'ai un petit projet de validation de concept dans lequel je stocke ensemble les fichiers que je suis susceptible d'ouvrir ensemble, ce qui me procure un confort considérable. Comme ces fichiers sont également susceptibles de s’appeler, ils peuvent le faire avec des liens relatifs plus courts et moins fragiles. Mvc conteste ce modèle, 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 \ controllers \ schism.

Cette page de Microsoft introduit le concept de zones. Cela peut être lu comme un aveu de la lourdeur des grandes applications à 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 disposant de fichiers sources séparés. Il me semble qu’il n’ya aucun avantage concret à prendre ces fichiers source étroitement couplés et à les envoyer aux extrémités opposées de la structure de dossiers?

Est-ce que quelqu'un d'autre lutte contre ça? Des conseils?

J'aimerais dire qu'il s'agit d' une programmation culte de la cargaison , mais cette structure a des raisons techniques. Asp.Net MVC a adopté une convention concernant la configuration pour presque tout. Par défaut, le moteur de vue Razor effectue une recherche dans le Viewsrépertoire afin de déterminer la vue à retourner à partir du contrôleur. Il existe cependant quelques astuces 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 est-ce que je dis que c'est de la programmation culte du fret et que vous avez raison? Oncle Bob m'a convaincu que la structure de répertoires du projet ne devrait pas me dire que c'est une application MVC. Cela devrait me dire que c'est un magasin, un système de demande de congés, ou autre chose. La structure et l'architecture de haut niveau devraient nous indiquer en quoi consiste cette chose et non comment elle a été mise 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 en sorte que le cadre Asp.Net MVC fasse quelque chose qui n’était pas le cas. pas conçu pour faire. Dommage que ce ne soit pas vraiment configurable.

Pour résoudre rapidement les problèmes d’architecture, j’estime toujours que les modèles commerciaux (entreprise, pas de vue) et le DAL doivent résider dans un projet / une bibliothèque distinct (e) appelé (e) depuis votre application MVC.

C'est juste que le contrôleur est vraiment très étroitement associé à la vue et susceptible d'être modifié ensemble. Il est judicieux de garder à l'esprit la différence entre le couplage par dépendance et le couplage logique. Le fait que les dépendances du code aient été découplées ne le rend pas moins couplé logiquement.

Quelle que soit la raison, c'est une mauvaise pratique. Il est très anti-OO car les paquetages ou les dossiers (peu importe comment vous les appelez) devraient avoir des interdépendances faibles. Les classes (ou fichiers) qu’elles contiennent doivent avoir de fortes interdépendances.

En plaç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 étroit. Cela va à l’encontre du principe de faibles dépendances inter-packages.

Une vue et un contrôleur sont deux moitiés d'un tout et devraient appartenir l'un à l'autre. Vous n'auriez pas un tirage d'armoire pour les chaussettes du côté gauche et un autre pour les chaussettes du 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 de savoir quelle combinaison est une véritable cause, puisqu'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

• En dehors des conventions et de la commodité, suivre le modèle de projet ASP.net MVC

• Pour grouper par espace de noms, puisque le Controllers/dossier mènera à un .Controllersespace de noms

• Peut activer certains scénarios dans DI / IoC où les classes de contrôleur ne sont interrogées / analysées qu'à partir d'un espace de noms contenant / ends-avec 'Contrôleurs' (cela peut être erroné)

• Permettre aux modèles T4 d'analyser et d'échafauder des modèles et des contrôleurs afin 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 tout le monde peut constituer un meilleur choix (mais pas nécessairement la bonne!).

Si votre convention est plus facile à suivre et n'entrave pas la productivité, alors faîtes-le! et peut-être même écrire un article de blog ou deux 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 front-end et back-end travaillent sur un projet. Vous pouvez empêcher les développeurs frontaux d'accéder au code final (par exemple, pour aider à la conformité PCI, restreindre l'accès aux codes sensibles).

Une autre raison est qu'il est plus facile d'avoir des "thèmes" et de supprimer tous les modèles en apportant une modification mineure au chemin de la vue.

Une troisième raison est d'avoir un modèle de répertoire simple lors de la spécification de vues dans l'infrastructure MVC. Il est plus facile de spécifier le sous-répertoire et le fichier plutôt qu'un long chemin d'accès à chaque vue.

Le seul "couplage étroit" devrait être:

1. Variables envoyées dans la vue par le contrôleur.
2. 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 plusieurs 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 points de vue entièrement séparés. Le modèle est l'endroit où vous pouvez différencier chaque "élément" de 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 namespaced. Vous pouvez ensuite utiliser un script pour copier ou "compiler" vos modèles bruts dans le répertoire "vues" principal. 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, les répertoires de paquetage sont plus compliqués pour mettre à jour les vues.

Considérez que les vues ne sont qu'un moyen de formater des données, que ce soit en json, xml, csv ou html. Cela est particulièrement utile si vous souhaitez que votre application fonctionne également en tant qu'API. Essayez de découpler la vue des données en utilisant des noms de variables génériques, de sorte que vous puissiez utiliser le même modèle pour de nombreux contrôleurs ou modèles (ou utiliser includes pour minimiser la quantité de code que vous devez gérer).

Pas nécessairement tout le monde fait ça. 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, vues et modèles (les vues sont essentiellement ce que Django appelle les contrôleurs). Je préfère cette façon de faire parce que cela signifie que je peux facilement empaqueter une "application" et la réutiliser dans des projets simplement en l'incluant dans la liste des applications dans les paramètres de mes projets. Il est également plus facile de savoir où se trouvent les différentes parties. Si je regarde le fichier urls.py et que url(r'^users/', include('my_site.users.urls'))je vois quelque chose comme , je sais que le module my_site.userscontient tout le code qui gère les utilisateurs. Je sais regarder les modules my_site.users.viewset my_site.users.modelsquand 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 assez générique, je peux probablement utiliser ce module dans d'autres sites en modifiant simplement la configuration ou en le conditionnant sous forme de bibliothèque et en le publiant sous forme de logiciel libre.

N’oubliez pas que c’est la méthode recommandée par Microsoft pour conserver les contrôleurs et les vues dans un dossier différent, de sorte que bon nombre d’entre eux respecteraient la structure recommandée.

1. L'une des raisons pourrait être que les contrôleurs n'ont pas toujours une relation un à un avec les vues, en particulier les vues partielles peuvent être partagées entre les contrôleurs.
2. Une autre raison pourrait être que lorsque votre projet grandit, vous souhaiterez peut-être extraire les contrôleurs et les tests unitaires vers un autre projet, mais il est assez difficile de faire la même chose, car les vues et les vues / js / css vont ensemble car elles se réfèrent.

Cela dit, il existe de nombreux articles sur le sujet, comme celui- ci .

Pour le compte rendu

Pourquoi est-ce que je dis que c'est de la programmation culte du fret et que vous avez raison? Oncle Bob m'a convaincu que la structure de répertoires du projet ne devrait pas me dire que c'est une application MVC. Cela devrait me dire que c'est un magasin, un système de demande de congés, ou autre chose. La structure et l'architecture de haut niveau devraient nous indiquer en quoi consiste cette chose et non 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, code. Ou plus spécifiquement, des classes basées sur des types (contrôleurs, service, modèle, etc.). Il est donc logique et facile de déboguer un code si vous êtes en mesure de trouver un code basé sur le type de code, plutôt que sur le comportement du code. De plus, disons un projet d'équipe, l'un est responsable 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 sucre de syntaxe. Oncle Bob a encore tort.

Essayer de reproduire le comportement du projet (une devanture de magasin) est un culte du fret.