Où sont les règles de gestion dans MVC

Question

Maintenant que tout le monde parle de MVC, je remarque que les règles commerciales ne sont pas traitées. A l'époque de l'architecture à 3 niveaux, les règles de gestion se situaient dans la couche intermédiaire. Où se situent-ils dans le nouveau MVC?

Answer 1

Au premier coup de pinceau, je dirais qu'ils appartiennent au modèle. La l'entrée MVC sur Wikipedia semble concorder: "Dans MVC, le modèle représente les informations (les données) de l'application et les règles de gestion utilisées pour manipuler les données ". Après tout, par «règles de gestion», nous entendons les algorithmes fonctionnels et la logique qui codent le domaine dans lequel votre application est impliquée, par opposition à la logique liée aux entrées / sorties. Cette logique métier essentielle ne change pas - ou ne devrait pas - changer en fonction de ce qui est affiché à l'utilisateur (qui est le domaine de la vue) ou de l'entrée de l'utilisateur (qui est principalement reçue par le contrôleur).

D'après mon expérience, poser ce type de question a été très révélateur au cours du processus de développement logiciel: nous avons trouvé un grand nombre d'éléments que certaines personnes considéraient comme des "règles de gestion", mais qui se sont révélés être autre chose. Si ce n'est pas une vraie règle métier, il est possible qu'elle n'appartienne pas au modèle.

Answer 2

La raison pour laquelle vous ne voyez jamais l'adresse MVC " Règles de gestion " est-ce que MVC en gros est un modèle de présentation. Il s’agit de structurer votre application. Le modèle, par exemple, peut être considéré comme un modèle de présentation. Le modèle de votre application, que la vue restitue ensuite.

Toutefois, pour créer le modèle de présentation, vous devez généralement vous rendre dans les modèles de domaine où réside toute votre logique métier. À ce stade, MVC ne dicte pas où ce code réside physiquement. Est-ce sur un autre niveau? MVC s'en fiche.

Answer 3

Les règles de gestion résident toujours dans le modèle. Le modèle est le bit que vous pourriez réutiliser avec une interface utilisateur complètement différente. La vue dépend évidemment entièrement des choix d’UI et le contrôleur doit extraire les données du modèle et indiquer à la vue de la restituer.

Il est mauvais de placer la logique métier dans la vue, car elle lie la structure à la présentation.

La logique métier dans le contrôleur est une mauvaise solution car elle divise le domaine de votre activité entre les données persistantes du modèle et les règles du contrôleur.

Answer 4

Citation d'un article de Wikipedia:

MVC apparaît souvent dans les applications Web, où la vue est la page HTML proprement dite et le contrôleur est le code qui collecte les données dynamiques et génère le contenu au sein du code HTML. Enfin, le modèle est représenté par le contenu réel, généralement stocké dans une base de données ou dans des nœuds XML, et les règles de gestion transformant ce contenu en fonction des actions de l'utilisateur.

Answer 5

Y a-t-il une raison pour laquelle vous ne pouvez pas mélanger MVC et Ntier? Notre application ne fait que cela. Nos contrôleurs sont utilisés pour la validation des données et décident des appels à effectuer dans la couche de gestion.

OurApp.Web - Projet Asp.net MVC
OurApp.Business - Bibliothèque de la couche de gestion
OurApp.DataAccess - Bibliothèque de couches de données
OurApp.Entities - Fondamentalement tous les "modèles" partagés par toutes les couches

Answer 6

Les règles de gestion doivent figurer dans le modèle, PAS dans le contrôleur. Le contrôleur et la vue font partie de la couche de présentation.

Le modèle représente les entités et les fonctionnalités du domaine.

Le contrôleur est simplement un gestionnaire permettant de saisir les entrées et les demandes des utilisateurs, d'effectuer des actions dans / sur le modèle et de les mapper aux vues de la couche de présentation. Le contrôleur n'est pas simplement un médiateur, le contrôleur de vue OU peut agir sur le modèle.

Answer 7

Cette question a été postée jadis, mais j'aime bien qu'un référentiel de règles soit complètement indépendant de toute partie d'une application. Plusieurs applications, plusieurs implémentations d'un niveau métier, doivent pouvoir accéder à un rendu statique d'un référentiel de règles métier. De simples décisions de séparation telles que celle-ci font une migration à partir du bureau - > Web, par exemple, trivial.

Dans mon architecture, Afficher - > Modèle - > Contrôleur - > Niveau entreprise - > Le référentiel de règles, c’est-à-dire que le contrôleur accède aux données brutes présentées par le niveau / couche de gestion, les transfère au modèle qui les modifie sous une forme présentable et que la vue l’affiche de manière passive. La couche métier, qui peut être réutilisée dans n’importe quel format de présentation, aura des règles explicites et un accès à un sous-système avec des règles implicites. De par leur conception, chaque composant ignore les détails d'un composant situé au-dessus de lui.

Answer 8

Je pense que le problème est une question de définition. Il me semble que la logique pour présenter les écrans dans l'ordre requis est un problème de contrôleur et j'ai vu des projets qui utilisent un moteur de règles pour déterminer l'ordre et ce qui est requis de la part de l'utilisateur. Ce n'est pas la même chose que les règles commerciales imho.

Answer 9

Vous vous trompez, les règles de gestion évoluent dans le contrôleur et non dans le modèle ...