Logique métier dans MVC [fermé]

184

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.

design-patterns model-view-controller business-logic business-rules hmthur
la source

173

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.

Boue
la source

5

Merci pour l'exemple. Pour l'entrée de courrier électronique de l'administrateur (contrôler si elle peut être supprimée ou non), ne pouvons-nous pas contrôler cela en utilisant notre contrôleur?

hmthur

2

@mud et si nous divisons notre modèle en deux couches supplémentaires, à savoir la couche de service et le référentiel ... la couche de service est responsable de la logique métier et le référentiel est responsable de la couche de données ...?

Dragon

3

@PeterMatisko "Les modèles ne doivent transporter que des données." Vous ne comprenez pas ce que M signifie dans "MVC". V est purement présentation. C est la colle entre la présentation et le modèle. (En fait, les "VC" sont souvent considérés ensemble comme la couche de présentation, et les variantes populaires de MVC comme MVVM - Model View Viewmodel - rendent cela encore plus clair.) Le M est tout le reste : toutes les données et la logique de votre application. Vous pouvez séparer les données et la logique métier au sein de cette couche, et vous pouvez appeler la partie données de cette couche votre «modèle», mais ce n'est pas ce à quoi fait référence le «M» dans «MVC».

Mud

1

@PeterMatisko "dans laravel, les gens jettent alors tout dans les contrôleurs ou les modèles. Mauvaise mauvaise architecture." Mauvais comment ? Être spécifique. «V» signifie «vue». Tout ce qui n'est pas une vue entre nécessairement en "M" ou "C". "MVC n'est tout simplement pas suffisant, il ne parle pas explicitement de logique métier et où le mettre" Bien sûr. «M» est le modèle de votre application, c'est-à-dire vos données, la logique métier qui l'entoure et tout ce qui n'est pas une présentation. "V" et "C" sont la couche de présentation, l'entrée et la sortie utilisateur.

Mud

2

@Mud Le problème est que laravel appelle un «modèle» juste un support de données. Lorsque les didacticiels disent que Laravel utilise MVC et que vous voyez que «Modèle» a un objectif très spécifique, vous vous retrouvez sans aucune idée de l'endroit où placer la logique métier. Et le seul endroit raisonnable est le contrôleur, ce qui n'est pas bon. Je n'invente pas cela, je viens de commenter les projets laravels typiques (et les tutoriels) que je vois souvent.

Peter Matisko

191

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.

Franc
la source

10

+1 pour répertorier correctement la différence entre l'application mvc et n-tier. La plupart des applications d'entreprise que je développe ont n-tiers et utilisent mvc comme couche de présentation uniquement.

Retired_User

Disons 1) Afficher les modèles dans MVC (Presentation Layer) 2) Certaines technologies C # (Business Layer) pour les transactions autorisées, logique des règles métier de base. 3) Référentiel et unité de travail dans (Data Access Layer) Veuillez guider certaines technologies (ou Best Practiced Patterns) qui peuvent être utilisées pour créer une couche métier qui devrait être libre d'autoriser et d'exposer le modèle, le référentiel à accéder à partir du contrôleur dans la couche de présentation (supérieur Couche). Fondamentalement, je crois que Ajouter, supprimer, mettre à jour et sa combinaison en tant que logique commerciale et devrait être conservé sous Transactions. Veuillez diffuser un peu plus de lumière à ce sujet.

Mark Macneil Bikeio

Salut Rahul, si je vous comprends bien, alors vous avez raison. Les opérations CRUD sont essentiellement des parties atomiques des transactions commerciales. Personnellement, je préfère utiliser un puissant mappeur OR comme Hibernate comme référentiel au lieu de créer le mien. En effet, hibernate implémente déjà l'unité de modèle de travail en interne. De plus, je place généralement les transactions commerciales dans des services commerciaux distincts.

Frank

Pour le modèle de vue, je peux vous donner l'exemple suivant: Juste une image, vous avez une interface graphique avec une vue à double liste. Cette vue à double liste utilise un modèle de vue à double liste comme modèle de données. Ce modèle de données n'est qu'une composition de deux listes simples. Le modèle de vue à double liste dépend donc de l'implémentation de la couche de présentation car il ne fait pas partie de votre modèle de domaine, contrairement aux deux listes simples qui sont utilisées pour créer le modèle de vue. En fonction de l'interface graphique que vous souhaitez créer, il existe plusieurs cas dans lesquels vous souhaiterez peut-être lier un modèle spécifique de vue à une vue au lieu de votre modèle de domaine.

Frank

La partie règles métier / logique est un peu difficile à expliquer. Afin de démarrer tout traitement de données, vous appelez une méthode depuis l'un de vos services. Cela signifie que vous démarrez essentiellement une transaction. Si cette méthode contient la logique métier, elle est appelée "script de transaction". C'est généralement une mauvaise chose car il est difficilement réutilisable. Il serait préférable que cette méthode appelle la logique métier de votre modèle de domaine. Cela signifie que votre modèle de domaine doit être conçu de manière à pouvoir contenir la logique métier. Cette approche axée sur le domaine ne fonctionnera pas avec un modèle de domaine incomplet ou incorrect.

Frank

73

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:

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 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.

Pete
la source

1

C'est très vrai! Il existe deux modèles ici: votre modèle de vue et votre modèle de domaine. Je pense qu'il est presque dommage que la disposition des projets MVC amène les développeurs novices à croire qu'ils devraient simplement entasser leur code dans le modèle de vue.

Jonathan

1

J'ai trouvé votre réponse plus acceptable et compréhensible. Merci.

revo

27

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.

décyclone
la source

16

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.

treefiddy
la source

2

Meilleure réponse en la matière. Devrait être voté plus haut. La pire réponse est marquée comme acceptée.

Peter Matisko

Meilleure réponse .. sans aucun doute

salman

Cela dépend-il de la taille des données et de l'application? Pour une petite application, je suppose que toute la logique pourrait entrer dans les modèles sans aucune confusion. Si oui, quel est le seuil de taille pour commencer à se séparer en un calque séparé?

mLstudent33

15

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):

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 indépendante de l'interface utilisateur du modèle, et
référentiel - la partie du "modèle" compatible avec le stockage.

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».

G. Stoynev
la source

5

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):

Alex
la source

Souhaitez-vous clarifier cette déclaration? "Un modèle contient les données provenant de la couche de gestion qui passent à la vue à afficher."

Anthony Rutledge

2

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

Alisa
la source

0

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.

Anil
la source

-5

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.

Hoven
la source

Si vous placez des règles métier dans le contrôleur et que vous avez de très nombreuses actions, allez-vous répliquer la règle métier de nombreuses fois? Non. Vous allez le séparer dans une méthode d'aide ou une classe quelconque. Mettez cette «chose» dans le modèle, à sa place.

G.Stoynev

3

MVC n'est pas un modèle d'application pour les opérations de base de données CRUD (bien qu'il puisse être utilisé de cette façon), par conséquent, le modèle ne peut pas être un «code pour les opérations de base de données CRUD». Le modèle définit les entités de l'application, y compris les données et les règles métier. Le contrôleur coordonne l'interaction entre la vue et le modèle. La vue est l'interface utilisateur exposant le modèle et les opérations disponibles dans les modèles exposés par le contrôleur.

Jon Davis

Logique métier dans MVC [fermé]

Réponses: