J'ai 2 questions:
Q1. Où se situe exactement la «logique métier» dans le modèle MVC? Je suis confus entre le modèle et le contrôleur.
Q2. La «logique métier» est-elle la même que les «règles métier»? Sinon, quelle est la différence?
Ce serait formidable si vous pouviez expliquer avec un petit exemple.
Réponses:
Les règles métier sont intégrées au modèle.
Supposons que vous affichez des e-mails pour une liste de diffusion. L'utilisateur clique sur le bouton «supprimer» à côté de l'un des e-mails, le contrôleur notifie au modèle de supprimer l'entrée N, puis informe la vue que le modèle a changé.
Peut-être que l'e-mail de l'administrateur ne devrait jamais être supprimé de la liste. C'est une règle métier, cette connaissance appartient au modèle. La vue peut finalement représenter cette règle d'une manière ou d'une autre - peut-être que le modèle expose une propriété "IsDeletable" qui est une fonction de la règle métier, de sorte que le bouton de suppression dans la vue est 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 le gardien de vos données. Vous devriez pouvoir tester votre logique métier sans toucher du tout à l'interface utilisateur.
Tout d'abord:
je crois 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 aider si vous voyez MVC plus comme une extension de la couche de présentation.
Si vous mettez du code de non-présentation dans le modèle MVC, vous risquez très bientôt de vous retrouver dans une conception compliquée.
Par conséquent, je vous suggère de placer votre logique métier dans une couche métier distincte.
Jetez un œil à ceci: Article de Wikipedia sur l'architecture à plusieurs niveaux
Il dit:
Aujourd'hui, MVC et MVP (Model-View-Presenter) sont des modèles de conception de séparation des préoccupations 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 à l'intérieur du contrôleur (de présentation).
En effet, le contrôleur gère réellement les appels à une ressource spécifique, interroge les données en appelant la logique métier et lie les données (modèle) à la vue appropriée.
Mud vous a dit que les règles commerciales entraient dans le modèle.
C'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 les niveaux.
Il est donc valide de placer vos règles métier liées à la base de données dans le modèle (couche de données) de votre application.
Mais vous ne devez pas les placer dans le modèle de votre couche de présentation structurée MVC car cela ne s'applique qu'à une interface utilisateur spécifique.
Cette technique est indépendante du fait que vous utilisiez une conception pilotée par domaine ou une approche basée sur un script de transaction.
Laissez-moi 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 le réduire 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 métier, 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 que de nos jours, il existe plusieurs "modèles" 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 commandes utilisées. La couche métier 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 de 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.
La question est: comment cela s'inscrit-il dans le concept MVC?
Réponse -> Non!
Eh bien - c'est un peu le cas, mais pas complètement.
En effet, MVC est une approche qui a été développée à la fin des années 1970 pour le langage de programmation Smalltalk-80. À 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 1990. À cette époque, les ordinateurs et les interfaces utilisateur étaient complètement différents de ceux des années 1970.
Vous devez 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.
Le terme logique métier n'est à mon avis pas une définition précise. Evans parle dans son livre, Domain Driven Design, de deux types de logique métier:
Cette séparation est à mon avis beaucoup plus claire. Et avec la prise de conscience qu'il existe différents types de règles commerciales, on se rend également compte qu'elles ne vont pas nécessairement toutes au même endroit.
La logique de domaine est une logique qui correspond au domaine réel. Donc, si vous créez une application comptable, les règles de domaine seraient des règles concernant les comptes, les écritures, la fiscalité, etc. etc.
Pour ces deux types d'applications, l'importation / exportation CSV peut être pertinente, mais les règles d'importation / exportation CSV n'ont rien à voir avec le domaine réel. Ce type de logique est une logique d'application.
La logique de domaine entre très certainement dans la couche modèle. Le modèle correspondrait également à la couche de domaine dans DDD.
Cependant, la logique d'application ne doit 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épendra de l'application réelle.
A1 : Business Logic entre Modelen jeu MVC. Le rôle de Modelest de contenir les données et la logique métier. Controllerd'autre part, il est responsable de recevoir les commentaires de l'utilisateur et de décider quoi faire.
A2 : A Business Rulefait partie de Business Logic. Ils ont une has arelation. Business Logica Business Rules.
Jetez un oeil à Wikipedia entry for MVC. Accédez à Aperçu où il mentionne le flux du MVCmodèle.
Regardez aussi Wikipedia entry for Business Logic. Il est mentionné qu'il Business Logicest composé de Business Ruleset Workflow.
Comme quelques réponses l'ont souligné, je pense qu'il y a un certain malentendu entre l'architecture multi-niveaux et MVC.
L'architecture multi-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. Pour ce faire, il faudrait 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 maintenable 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 d'appeler simplement la couche de logique métier à partir de vos modèles si nécessaire. La couche de logique métier appellera à son tour la couche d'accès aux données.
Je tiens à souligner qu'il n'est pas rare de trouver du code qui mêle logique métier et accès aux données dans l'un des composants MVC, surtout si l'application n'a pas été architecturée à l'aide de 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.
C'est une question avec réponse, mais je vais donner mon "un cent":
Les règles métier appartiennent au modèle. Le "modèle" se compose toujours de (séparés logiquement ou physiquement):
Les règles métier vivent dans le modèle de domaine, sont exposées sous une forme adaptée à la présentation au modèle de «présentation» et sont parfois dupliquées (ou également appliquées) dans la «couche de données».
Cela n'a aucun sens de placer votre couche de gestion dans le modèle d'un projet MVC.
Dites que votre patron décide de changer le calque de présentation en autre chose, vous seriez foutu! La couche de gestion doit être un assemblage distinct. Un modèle contient les données provenant de la couche de gestion qui passent à la vue à afficher. Ensuite, lors de 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 Person. Voici ce que je fais (la classe BusinessError est manquante mais irait également dans le BusinessLayer):
Q1:
Les logiques métier peuvent être considérées dans deux catégories:
Logiques de domaine comme les contrôles sur une adresse e-mail (unicité, contraintes, etc.), l'obtention du prix d'un produit pour facture, ou, le calcul du prix total de shoppingCart en fonction de ses objets produits.
Des flux de travail plus larges et compliqués que l'on appelle des processus métier, comme le contrôle du processus d'inscription de l'étudiant (qui comprend généralement plusieurs étapes et nécessite des vérifications différentes et présente des contraintes plus complexes).
La première catégorie entre dans le modèle et la seconde appartient au contrôleur . En effet, les cas de la deuxième catégorie sont des logiques d'application larges et les mettre dans le modèle peut mélanger l'abstraction du modèle (par exemple, il n'est pas clair si nous devons placer ces décisions dans une classe de modèle ou une autre, car elles sont liées aux deux!).
Voir cette réponse pour une distinction spécifique entre le modèle et le contrôleur, ce lien pour des définitions très exactes et aussi ce lien pour un bel exemple Android.
Le fait est que les notes mentionnées par "Mud" et "Frank" ci-dessus peuvent être aussi bien vraies que celles de "Pete" (la logique métier peut être mise en modèle, ou contrôleur, selon le type de logique métier).
Enfin, notez que MVC diffère d'un contexte à l'autre. Par exemple, dans les applications Android, certaines définitions alternatives sont suggérées qui diffèrent de celles basées sur le Web (voir cet article par exemple).
Q2:
La logique métier est plus générale et (comme "décyclone" mentionné ci-dessus) nous avons la relation suivante entre elles:
règles métier ⊂ logiques métier
Pourquoi n'introduisez-vous pas une couche de service. alors votre contrôleur sera maigre et plus lisible, alors toutes vos fonctions de contrôleur seront de pures actions. vous pouvez décomposer la logique métier autant que vous le souhaitez dans la couche de service. la réutilisabilité du code est élevée. aucun impact sur les modèles et les référentiels.
Modèle = code pour les opérations de base de données CRUD.
Controller = répond aux actions de l'utilisateur et transmet les demandes de récupération ou de suppression / mise à jour des données au modèle, sous réserve des règles métier spécifiques à une organisation. Ces règles métier peuvent être implémentées dans des classes d'assistance, ou si elles ne sont pas trop complexes, juste directement dans les actions du contrôleur. Le contrôleur demande enfin à la vue de se mettre à jour afin de donner un retour à l'utilisateur sous la forme d'un nouvel affichage, ou d'un message du type `` mis à jour, merci '', etc.,
View = UI générée sur la base d'une requête sur le modèle.
Il n'y a pas de règles strictes concernant la destination des règles métier. Dans certains modèles, ils vont dans le modèle, tandis que dans d'autres, ils sont inclus avec le contrôleur. Mais je pense qu'il vaut mieux les garder avec le contrôleur. Laissez le modèle se soucier uniquement de la connectivité de la base de données.