Maintenant que tout le monde parle de MVC, je remarque que les règles métier ne sont pas traitées. Dans les anciens jours de l'architecture à trois niveaux, les règles métier étaient dans la couche intermédiaire. Où tombent-ils dans le nouveau MVC?Où sont les règles métier dans MVC
Au premier pinceau, je dirais qu'ils appartiennent au modèle. Le MVC Entry on Wikipedia semble être d'accord: "Dans MVC, le modèle représente l'information (les données) de l'application et les règles métier utilisées pour manipuler les données". Après tout, par «règles métier», nous entendons les algorithmes fonctionnels et la logique qui codent le domaine auquel votre application est associée, par opposition à la logique liée aux entrées/sorties. Cette logique liée au métier 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 à l'entrée de l'utilisateur (qui est principalement reçue par le contrôleur). D'après mon expérience, poser ce genre de question a été très révélateur au cours du processus de développement logiciel: nous avons trouvé un grand nombre de choses qui étaient considérées comme des «règles d'affaires» par certaines personnes, mais qui se sont avérées être autre chose. Si ce n'est pas une véritable règle métier, il se peut qu'elle n'appartienne pas au modèle.
Le modèle ne devrait cependant pas être dans le projet MVC et il ne devrait pas avoir de dépendances sur une technologie d'interface utilisateur particulière. – Andy
Une citation d'un Wikipédia Article:
MVC est souvent vu dans les applications Web, où la vue est la page HTML réelle, et le contrôleur est le code qui collecte les données dynamiques et génère le contenu dans le 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 les nœuds XML, et les règles métier qui transforment ce contenu en fonction des actions de l'utilisateur.
Ce n'est pas MVC. MVC consiste à organiser le code. Toutes les pages Web dynamiques seraient MVC selon votre définition. –
Y at-il une raison pour laquelle vous ne pouvez pas mélanger MVC et Ntier? Notre application fait juste cela. Nos contrôleurs sont utilisés pour la validation des données et déterminent les appels de couche métier à effectuer.
OurApp.Web - Asp.net MVC Projet
OurApp.Business - Bibliothèque de la couche d'affaires
OurApp.DataAccess - Couche de données Bibliothèque
OurApp.Entities - Fondamentalement, tous les 'modèles' partagée par toutes les couches
J'aime cette approche. Malheureusement, je pense que de nombreux frameworks web rendent ce saut inconfortable. À un moment donné, vous pourriez avoir besoin d'objets auxiliaires dans votre couche de gestion qui ne correspondent pas nécessairement à des tables de base de données/stockage persistant - quelque chose que chaque classe de modèle que j'ai vu semble être une chose fondamentale. À ce stade, vous vous demandez, où puis-je mettre ce code? – Koobz
Les règles métier sont toujours intégrées au modèle. Le modèle est le bit que vous pourriez réutiliser avec une interface utilisateur complètement différente. La vue est évidemment complètement dépendante des choix d'interface utilisateur et le contrôleur doit prendre des données du modèle et indiquer à la vue de le rendre.
La mise en logique métier dans la vue est mauvaise car elle lie la structure à la présentation.
La mise en logique métier dans le contrôleur est mauvaise car elle divise votre domaine métier entre les données persistantes du modèle et les règles du contrôleur.
La raison pour laquelle vous ne voyez jamais l'adresse MVC "Business Rules" est que MVC est en général un modèle de présentation. Il est axé sur la façon 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 rend ensuite. Toutefois, pour créer le modèle de présentation, vous devez généralement accéder à vos modèles de domaine où réside toute votre logique métier. À ce stade, MVC ne dicte pas où ce code vit physiquement. Est-ce sur un autre niveau? MVC s'en fiche.
Cela devrait être la réponse acceptée –
Vous avez tort, les règles de gestion se trouvent dans le contrôleur et non dans le modèle ...
des arguments là-bas? – Kamarey
Ce commentaire est tout simplement faux. Le contrôleur est une partie technique de l'application qui orchestre les flux de données et déclenche des actions dans le modèle et la vue. Dans une application PC typique, le contrôleur est concerné par les événements de la souris, les frappes au clavier et autres types de choses similaires. –
Les règles métier doivent être dans le modèle, PAS 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 de domaine et fonctionnalité ..
Le contrôleur est simplement un gestionnaire pour prendre l'entrée d'utilisateur et les demandes, effectuer des actions dans/sur le modèle et la cartographie que des vues dans la couche de présentation. Le contrôleur n'est pas seulement un médiateur, la vue OU le contrôleur peut agir sur le modèle.
Je pense que beaucoup de gens considèrent implicitement le modèle comme le «modèle de base de données», ce qui explique pourquoi les règles métier ne semblent pas avoir leur place. Si au lieu de cela, vous voyez le modèle comme une simulation de quelque chose du monde réel, alors il est évident que les règles métier font autant partie du modèle que les données qu'elles manipulent. –
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 certains projets qui utilisent un moteur de règles pour déterminer l'ordre et ce qui est requis par l'utilisateur. Ce n'est pas la même chose que les règles d'affaires.
Je crois que OP parle de la logique métier qui appartient au modèle. –
Il s'agit d'une ancienne question publiée, mais j'aime qu'un référentiel de règles soit complètement indépendant de n'importe quelle 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. Les décisions de séparation simples comme celle-ci font une migration de bureau -> web, par exemple, trivial. Dans mon architecture, View -> Model -> Controller -> Business Tier -> Référentiel de règles, ie le contrôleur accède aux données grossières présentées par le niveau/couche métier, le nourrit au modèle qui le masse dans un présentable forme, et la vue l'affiche passivement. Le niveau commercial, qui est réutilisable dans tous les formats de présentation, aura des règles explicites et un accès à un sous-système avec des règles implicites. Par conception, chaque composant ignore les détails d'un composant au-dessus.
Alors? Quicksort a 46 ans et est toujours utilisé. L'important est que cela fonctionne très bien. –
J'ai remarqué la même chose il y a quelques années. Il semblait que dès que je l'ai appris, il a commencé à apparaître partout où je regardais. –