Logique métier dans MVC
J'ai 2 questions:
Q1. Où se situe exactement la "logique métier" dans le modèle MVC? Je suis confus entre modèle et contrôleur.
Q2. La "logique métier" est-elle la même chose que les "règles métier"? Sinon, quelle est la différence?
Ce serait formidable si vous pouviez expliquer avec un petit exemple.
Les règles de gestion vont dans le modèle.
Supposons que vous affichiez des emails pour une liste de diffusion. L'utilisateur clique sur le bouton "Supprimer" en regard de l'un des courriers électroniques. Le contrôleur demande au modèle de supprimer l'entrée N, puis indique à la vue que le modèle a été modifié.
Le courrier électronique de l'administrateur ne devrait peut-être jamais être supprimé de la liste. C'est une règle de gestion, cette connaissance appartient au modèle. La vue peut en fin de compte représenter cette règle d’une manière ou d’une autre - le modèle expose peut-être une propriété "IsDeletable" qui est une fonction de la règle de gestion, de sorte que le bouton de suppression de la vue soit désactivé pour certaines entrées - mais la règle elle-même n'est pas contenue dans la vue.
Le modèle est finalement un portier pour vos données. Vous devriez pouvoir tester votre logique métier sans toucher à l'interface utilisateur.
Poing de tous:
Je pense que vous mélangez le modèle MVC et les principes de conception basés sur n niveaux.
L’utilisation d’une approche MVC ne signifie pas que vous ne devez pas superposer votre application.
Cela pourrait être utile si vous voyez MVC plutôt comme une extension de la couche de présentation.
Si vous insérez du code de non-présentation dans le modèle MVC, vous risquez très vite de vous retrouver dans une conception compliquée.
Par conséquent, je vous suggérerais de placer votre logique métier dans une couche de gestion distincte.
Jetez un coup d’œil à ceci: article de Wikipedia sur l’architecture à plusieurs niveaux
Ça dit:
Aujourd'hui, MVC et les modèles-vue-présentateurs (MVP) similaires sont des modèles de conception de séparation des problèmes qui s'appliquent exclusivement à la couche de présentation d'un système plus grand.
Quoi qu'il en soit ... lorsque vous parlez d'une application Web d'entreprise , les appels de l'interface utilisateur à la couche de logique métier doivent être placés dans le contrôleur (présentation).
En effet, le contrôleur gère les appels vers une ressource spécifique, interroge les données en appelant la logique applicative et relie les données (modèle) à la vue appropriée.
Mud vous a dit que les règles de gestion entrent dans le modèle.
Cela est également vrai, mais il a mélangé le modèle (de présentation) (le "M" dans MVC) et le modèle de couche de données d'une conception d'application basée sur une couche.
Il est donc valide de placer vos règles métier relatives à la base de données dans le modèle (couche de données) de votre application.
Cependant, vous ne devez pas les placer dans le modèle de votre couche de présentation à structure MVC, car cela ne s'applique qu'à une interface utilisateur spécifique.
Cette technique est indépendante du fait que vous utilisiez une conception basée sur un domaine ou une approche basée sur un script de transaction.
Permettez-moi de visualiser cela pour vous:
Couche de présentation: Modèle - Vue - Contrôleur
Couche métier: Logique de domaine - Logique d'application
Couche de données: référentiels de données - Couche d'accès aux données
Le modèle que vous voyez ci-dessus signifie que vous avez une application qui utilise MVC, DDD et une couche de données indépendante de la base de données.
Il s'agit d'une approche courante pour concevoir une application Web d'entreprise plus grande.
Mais vous pouvez également réduire le nombre de personnes pour utiliser une simple couche de gestion non DDD (une couche de gestion sans logique de domaine) et une simple couche de données qui écrit directement dans une base de données spécifique.
Vous pouvez même supprimer toute la couche de données et accéder à la base de données directement à partir de la couche de gestion, bien que je ne le recommande pas.
C'est le truc ... J'espère que cela aide ...
[Note:] Vous devez également être conscient du fait qu'il existe aujourd'hui plus d'un "modèle" dans une application. Généralement, chaque couche d'une application a son propre modèle. Le modèle de la couche de présentation est spécifique à la vue mais souvent indépendant des contrôles utilisés. La couche de gestion peut également avoir un modèle appelé "modèle de domaine". C'est généralement le cas lorsque vous décidez d'adopter une approche axée sur le domaine. Ce "modèle de domaine" contient des données ainsi que la logique métier (la logique principale de votre programme) et est généralement indépendant de la couche de présentation. La couche de présentation appelle généralement la couche de gestion sur un certain "événement" (bouton enfoncé, etc.) pour lire ou écrire des données dans la couche de données. La couche de données peut également avoir son propre modèle, qui est généralement lié à la base de données. Il contient souvent un ensemble de classes d'entités ainsi que des DAO (data-access-object).
La question est: comment cela s’intègre-t-il dans le concept MVC?
Réponse -> Ce n'est pas!
Eh bien, c'est un peu le cas, mais pas complètement.
En effet, MVC est une approche développée à la fin des années 1970 pour le langage de programmation Smalltalk-80. A cette époque, les interfaces graphiques et les ordinateurs personnels étaient assez rares et le World Wide Web n'était même pas inventé! La plupart des langages de programmation et des IDE actuels ont été développés dans les années 90. A cette époque, les ordinateurs et les interfaces utilisateur étaient complètement différents de ceux des années 1970.
Vous devriez garder cela à l’esprit lorsque vous parlez de MVC.
Martin Fowler a écrit un très bon article sur MVC, MVP et les interfaces graphiques actuelles.
À mon avis, le terme logique métier n’est pas une définition précise. Evans parle dans son livre Domain Driven Design de deux types de logique d’entreprise:
- Logique de domaine.
- Logique d'application.
Cette séparation est à mon avis beaucoup plus claire. Et avec la prise de conscience qu'il existe différents types de règles métier, vous réalisez également qu'elles ne vont pas nécessairement au même endroit.
La logique de domaine est une logique qui correspond au domaine réel. Ainsi, si vous créez une application comptable, les règles de domaine sont des règles concernant les comptes, les écritures, la fiscalité, etc. Dans un outil de planification logicielle agile, les règles consistent à calculer des dates de publication basées sur la vitesse et les etc.
L'importation/exportation au format CSV peut être pertinente pour ces deux types d'applications, mais les règles d'importation/exportation au format CSV n'ont rien à voir avec le domaine réel. Ce type de logique est la logique d'application.
La logique de domaine va très certainement dans la couche modèle. Le modèle correspondrait également à la couche de domaine dans DDD.
La logique d'application ne doit toutefois pas nécessairement être placée dans la couche de modèle. Cela pourrait être placé directement dans les contrôleurs ou vous pourriez créer une couche d'application distincte hébergeant ces règles. Ce qui est le plus logique dans ce cas dépend de l’application réelle.
A1 : la logique applicative passe à la partie Model de MVC. Le rôle de Model consiste à contenir les données et la logique métier. Controller d'autre part est responsable de recevoir les entrées de l'utilisateur et de décider quoi faire.
A2 : Un _Business Rule_ fait partie de _Business Logic_. Ils ont une relation _has a_. _Business Logic_ a _Business Rules_.
Jetez un oeil à Wikipedia entry for MVC . Aller à la vue d'ensemble où il mentionne le flux de modèle MVC.
Regardez aussi Wikipedia entry for Business Logic . Il est mentionné que _Business Logic_ est composé de _Business Rules_ et Workflow.
C'est une question à réponse, mais je vais donner mon "un cent":
Les règles de gestion appartiennent au modèle. Le "modèle" consiste toujours en (séparé logiquement ou physiquement):
- modèle de présentation - un ensemble de classes bien adapté à une utilisation dans la vue (il est adapté à une interface utilisateur/présentation spécifique),
- modèle de domaine - la partie du modèle indépendante de l'interface utilisateur, et
- référentiel - la partie du "modèle" prenant en compte le stockage.
Les règles métier résident dans le modèle de domaine, sont présentées sous une forme adaptée à la présentation au modèle "présentation" et sont parfois dupliquées (ou également appliquées) dans la "couche de données".
Comme l’ont souligné quelques réponses, j’estime que l’architecture multiniveau ou MVC est mal comprise.
L'architecture à plusieurs niveaux implique de diviser votre application en niveaux/couches (par exemple, présentation, logique métier, accès aux données).
MVC est un style architectural pour la couche de présentation d'une application. Pour les applications non triviales, la logique métier/les règles métier/l'accès aux données ne doivent pas être placés directement dans les modèles, les vues ou les contrôleurs. Cela reviendrait à placer la logique métier dans votre couche de présentation et à réduire ainsi la réutilisation et la maintenabilité de votre code.
Le modèle est un choix très raisonnable pour placer la logique métier, mais une approche meilleure/plus facile à maintenir consiste à séparer votre couche de présentation de votre couche de logique métier et à créer une couche de logique métier et à appeler simplement la couche de logique métier de vos modèles en cas de besoin. La couche de logique métier appelle à son tour la couche d'accès aux données.
Je voudrais souligner qu'il n'est pas rare de trouver du code combinant la logique métier et l'accès aux données dans l'un des composants MVC, en particulier si l'application n'a pas été architecturée à plusieurs niveaux. Cependant, dans la plupart des applications d'entreprise, vous trouverez généralement des architectures à plusieurs niveaux avec une architecture MVC en place dans la couche de présentation.
Cela n'a pas de sens de placer votre couche métier dans le modèle pour un projet MVC.
Dites que votre patron décide de changer le calque de présentation en quelque chose d'autre, vous seriez foutu! La couche de gestion doit être une assemblée séparée. Un modèle contient les données provenant de la couche de gestion qui sont transmises à la vue à afficher. Ensuite, à la publication, par exemple, le modèle se lie à une classe Person qui réside dans la couche de gestion et appelle PersonBusiness.SavePerson (p); où p est la classe de personne. Voici ce que je fais (la classe BusinessError manque mais irait aussi dans BusinessLayer): 
Q1:
Les logiques d’entreprise peuvent être considérées dans deux catégories:
Les logiques de domaine, telles que les contrôles sur une adresse électronique (unicité, contraintes, etc.), l'obtention du prix d'un produit à facturer ou le calcul du prix total du panier d'achat basé sur ses objets.
Des flux de travail plus larges et complexes, appelés processus métier, tels que le contrôle du processus d'inscription pour l'étudiant (qui comprend généralement plusieurs étapes, nécessite des vérifications différentes et comporte des contraintes plus compliquées).
La première catégorie passe dans le modèle et la deuxième on appartient à contrôleur . Cela s'explique par le fait que les cas de la deuxième catégorie correspondent à une logique d'application large et que leur insertion dans le modèle peut mélanger les abstractions du modèle (par exemple, il n'est pas clair s'il faut placer ces décisions dans une classe de modèle, car elles sont liées. aux deux!).
Voir ceci réponse pour une distinction spécifique entre modèle et contrôleur, ceci lien pour des définitions très précises et également ceci lien pour un Nice Android exemple.
Le fait est que les notes mentionnées par "Mud" et "Frank" ci-dessus peuvent être vraies, ainsi que par "Pete" (la logique métier peut être mise en modèle, ou en contrôleur, en fonction du type de logique métier).
Enfin, notez que MVC diffère d’un contexte à l’autre. Par exemple, dans les applications Android, il est suggéré de définir d'autres définitions qui diffèrent de celles basées sur le Web (voir this post par exemple).
Q2:
La logique métier est plus générale et (en tant que "décyclone" mentionné ci-dessus) nous avons la relation suivante entre eux:
règles métier log logiques métier