Que doivent représenter mes contrôleurs ASP.NET MVC - application "monde réel"

Question

J'ai une application Web établie construite sous la forme d'une application Web ASP.NET 3.5. Nous l'avons récemment modifié pour mélanger MVC dans l'application pour de nouvelles fonctionnalités. Maintenant que c'est là-dedans, nous voulons tirer parti de MVC dans la mesure du possible pour commencer à «transformer» l'application à partir de formulaires Web clunky à une application MVC plus maintenable et testable.

La question qui vient d'être posée en ajoutant de nouvelles fonctionnalités est de savoir quel contrôleur devrait être responsable d'une certaine action.

Permettez-moi d'être plus détaillé.

Le scénario implique au moins trois zones conceptuelles principales dans notre application. L'application doit pouvoir définir sa PREFERENCE pour une vue MAP par défaut lorsqu'elle est sur un écran de RECHERCHE. Préférences, cartes et recherche sont tous des concepts majeurs dans notre système. En outre, ce paramètre de préférence (essentiellement, où la carte devrait débuter) peut être utilisé pour définir la carte initiale dans plusieurs pages de recherche (il s'agit essentiellement d'une préférence de recherche).

Le contrôleur MVC existant dans l'application est un MAPCONTROLLER, avec 3 actions qui sont responsables de la génération de données HTML ou JSON à mettre sur une carte.

Ce que nous devons faire maintenant, est d'ajouter une route MVC (controller + action) pour permettre à la vue client d'enregistrer certaines informations selon leur préférence. Fondamentalement, chaque fois qu'ils sont sur la page de recherche en regardant une carte, ils peuvent cliquer sur un bouton qui dit «se souvenir de ceci comme vue de carte par défaut», et à partir de là, leur carte commencera toujours avec cette vue.

Ma question est (et je m'excuse, mais je voulais être très très clair, je vois trop de questions sans contexte pour aider). Que devrait représenter mon contrôleur? J'ai évidemment 3 grands domaines de système impliqués. Serait-il approprié de créer un nouveau contrôleur SEARCH ou PREFERENCES avec une action SaveDefaultMapView (aucune vue requise), ou piggyback sur le contrôleur MAP xistant, même si cette nouvelle fonction concerne plus la recherche et les préférences que la génération de cartes réelles? Un contrôleur MVC doit-il être aligné principalement sur l'écran (page de recherche/sous-système de recherche), sur le domaine/les données manipulées (préférences) ou sur l'élément visuel très spécifique examiné (carte)? Tous les exemples et les projets bootcamp sont tous très bien, mais ils sont beaucoup trop propre et simplifié pour s'appliquer à une application ancienne énorme. Comment concevoir leurs composants MVC autour d'un système qui intègre de nombreuses préoccupations de domaine dans une seule page Web?

Merci à tous!

Answer 1

Il n'y a pas de règles strictes pour l'organisation des contrôleurs. Vous les organisez comme cela vous semble logique. Cela nécessitera un peu d'expérimentation lorsque vous verrez comment le routage fonctionne, et vous trouverez le design le plus propre et le plus élégant. ASP12NET MVC est brillamment agnostique à cet égard. Il ne se soucie pas de savoir comment vous concevez votre sous-structure de contrôleur/route, et il est assez flexible pour gérer la plupart des conceptions.

Le design de votre application devrait être lourd du côté du modèle. Vos contrôleurs devraient être relativement petits. Si vous trouvez que vous bourrez une grande quantité de logique dans les contrôleurs, vous devez refactoriser cette logique au modèle ou ajouter une couche de service pour contenir la logique. Votre couche de contrôleur est mieux considérée comme un "panneau de brassage"; C'est l'endroit où vous connectez vos Urls entrants via des routes vers votre couche modèle/service et votre View Model/Views.

Vous devriez certainement vérifier Project Areas, car cela pourrait être un mécanisme approprié pour contenir vos trois différentes zones du système.

Answer 2

Merci, Robert. Je suppose que je pourrais reformuler un peu ... quelles directives les autres ont trouvé utiles pour garder leurs responsabilités de contrôleur organisées et logiques? Alors que mon exemple ci-dessus ne concerne que 3 de nos domaines, je prévois de remplacer la plupart/toute l'application avec MVC. En outre, chacune des trois zones que j'ai mentionnées a des relations avec plusieurs autres domaines (par exemple, les cartes peuvent être utilisées pour tracer plusieurs entités géolocalisées, les préférences peuvent s'appliquer à n'importe quelle zone du système et, comme les cartes, recherche de plusieurs types d'entités commerciales (une à la fois, pas toutes ensemble) Donc, les lignes sont floues, je suis intéressé à entendre comment les autres ont trouvé des directives pratiques pour l'organisation du contrôleur Oh, et à tout le moins, nous nous en tenons au paradigme contrôleur maigre/gros modèle!