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 confondu entre Model et Controller.

Q2. La “logique métier” est-elle la même que les “règles métier”? Sinon, quelle est la différence?

Ce serait bien si vous pouviez expliquer avec un petit exemple.

    Les règles métier vont dans le modèle.

    Supposons que vous affichez des emails pour une liste de diffusion. L’utilisateur clique sur le bouton “Supprimer” à côté de l’un des e-mails, le contrôleur avertit le modèle pour supprimer l’entrée N, puis notifie la vue que le modèle a changé.

    Le courrier électronique de l’administrateur ne devrait peut-être jamais être retiré 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 le modèle expose-t-il une propriété “IsDeletable” qui est fonction de la règle métier, de sorte que le bouton Supprimer de la vue soit désactivé pour certaines entrées – dans la vue.

    Le modèle est finalement le gardien de vos données. Vous devriez être capable de tester votre logique métier sans toucher à l’interface utilisateur.

    Le poing de tous:
    Je crois que vous mélangez le modèle MVC et les principes de conception basés sur n-tiers.

    Utiliser une approche MVC ne signifie pas que vous ne devriez pas superposer votre application.
    Cela pourrait être utile si vous considérez MVC 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 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 coup d’oeil à ceci: article de Wikipedia sur l’architecture multiniveau

    Ça dit:

    Aujourd’hui, MVC et MVP (Model-View-Presenter) similaires sont des modèles de conception de Separation of Concern 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 vers la couche logique métier doivent être placés dans le contrôleur (de présentation).

    En effet, le contrôleur gère les appels vers 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 de gestion entraient 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 des niveaux.
    Il est donc valable de placer les règles métier relatives à la firebase database dans le modèle (couche de données) de votre application.
    Mais vous ne devriez pas les placer dans le modèle de votre couche de présentation structurée par MVC, car cela ne s’applique qu’à une interface utilisateur spécifique.

    Cette technique est indépendante de la manière dont vous utilisez 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’access 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 firebase database.
    Il s’agit d’une approche courante pour concevoir une application Web 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 couche de données simple qui écrit directement dans une firebase database spécifique.
    Vous pouvez même supprimer toute la couche de données et accéder à la firebase database directement depuis la couche de gestion, même si je ne le recommande pas.

    C’est le truc … J’espère que ça aide …

    [Note:] Vous devez également être conscient du fait qu’aujourd’hui, il n’ya pas qu’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 basé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épendante 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 pressé, etc.) pour lire ou écrire des données sur la couche de données. La couche de données peut également avoir son propre modèle, généralement associé à une firebase database. Il contient souvent un ensemble de classes d’entités ainsi que des objects d’access aux données (DAO).

    La question est: comment cela s’intègre-t-il dans le concept MVC?

    Réponse -> Ce n’est pas le cas!
    Eh bien, c’est un peu, mais pas complètement.
    C’est parce que MVC est une approche qui a été 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. À 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.

    Le terme de logique métier n’est pas à mon sens 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, il faut aussi prendre conscience 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 de comptabilité, alors les règles de domaine seraient des règles concernant les comptes, les écritures, la fiscalité, etc. Dans un outil de planification logiciel agile, les règles seraient les suivantes: calcul des dates de publication etc.

    Pour ces deux types d’applications, l’importation / exportation au format CSV peut être pertinente, 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 cependant pas nécessairement être placée dans la couche 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 proprement dite.

    A1 : La logique métier va à la pièce Model dans MVC . Le rôle du Model consiste à contenir des données et une logique métier. Controller à lui, est responsable de recevoir les commentaires des utilisateurs et de décider quoi faire.

    A2 : Une Business Rule fait partie de Business Logic . Ils ont has a relation. Business Logic a Business Rules .

    Jetez un coup d’oeil à Wikipedia entry for MVC . Aller à l’aperçu où il mentionne le stream de modèle MVC .

    Consultez également Wikipedia entry for Business Logic . Il est mentionné que Business Logic comprend Business Rules et le Workflow .

    Ceci est une question répondue, mais je vais donner mon “un cent”:

    Les règles métier appartiennent au modèle. Le “modèle” consiste toujours à (logiquement ou physiquement séparé):

    • modèle de présentation – un ensemble de classes bien adapté à une utilisation dans la vue (adapté à une interface utilisateur / présentation spécifique),
    • modèle de domaine – la partie du modèle indépendante de l’interface utilisateur, et
    • repository – la partie du “modèle” compatible avec le stockage.

    Les règles métier du modèle de domaine sont exposées sous une forme adaptée à la présentation au modèle «présentation» et sont parfois dupliquées (ou appliquées) dans la «couche de données».

    Comme le soulignent quelques réponses, je pense que l’architecture multiniveau et l’architecture MVC sont mal comsockets.

    L’architecture multiniveau implique de diviser votre application en niveaux / couches (par exemple, présentation, logique métier, access aux données)

    MVC est un style architectural pour la couche de présentation d’une application. Pour les applications non sortingviales, la logique métier / les règles métier / l’access aux données ne doivent pas être placés directement dans les modèles, les vues ou les contrôleurs. Pour ce faire, placez la logique métier dans votre couche de présentation et réduisez 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. La couche de logique métier appelle à son tour la couche d’access aux données.

    Je tiens à souligner qu’il n’est pas rare de trouver du code qui associe la logique métier et l’access aux données dans l’un des composants MVC, en particulier si l’application n’a pas été conçue avec plusieurs niveaux. Cependant, dans la plupart des applications d’entreprise, vous trouverez généralement des architectures multi-niveaux avec une architecture MVC au sein de la couche de présentation.

    Il est inutile de placer votre couche de gestion dans le modèle pour un projet MVC.

    Disons que votre patron décide de changer la couche de présentation en autre chose, vous seriez foutu! La couche métier doit être un assembly distinct. Un modèle contient les données provenant de la couche de gestion transmise à la vue à afficher. Par la suite, 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 aussi dans le BusinessLayer): entrer la description de l'image ici

    Q1:

    Les logiques métier peuvent être classées en deux catégories:

    1. Les logiques de domaine, comme les contrôles sur une adresse e-mail (unicité, contraintes, etc.), l’obtention du prix d’un produit à facturer ou le calcul du prix total du shoppingCart en fonction des objects produits.

    2. Des workflows plus larges et compliqués, appelés processus métier, comme le contrôle du processus d’inscription pour l’étudiant (qui comprend généralement plusieurs étapes et nécessite des contrôles différents et des contraintes plus complexes).

    La première catégorie entre dans le modèle et la seconde appartient au contrôleur . Cela est dû au fait que les cas de la deuxième catégorie sont des logiques d’application étendues et qu’il est possible de les incorporer dans le modèle (par exemple, il n’est pas clair si nous devons placer ces décisions dans une classe de modèle. aux deux!).

    Voir cette réponse pour une distinction spécifique entre modèle et 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 vraies aussi bien que “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, des définitions alternatives différentes de celles basées sur le Web (voir cet article par exemple).


    Q2:

    La logique métier est plus générale et (comme “decyclone” mentionné ci-dessus) nous avons la relation suivante entre eux:

    règles métier ics logiques métier

    Modèle = code pour les opérations de firebase database CRUD.

    Controller = répond aux actions de l’utilisateur et transmet les demandes de récupération ou de suppression / mise à jour au modèle, sous réserve des règles métier spécifiques à l’entreprise. Ces règles métier peuvent être implémentées dans des classes auxiliaires ou, si elles ne sont pas trop complexes, directement dans les actions du contrôleur. Le contrôleur demande enfin à se mettre à jour afin de donner un retour à l’utilisateur sous la forme d’un nouvel affichage ou d’un message tel que “mis à jour, merci”, etc.,

    View = UI générée en fonction d’une requête sur le modèle.

    Il n’y a pas de règles ssortingctes concernant les règles métier. Dans certains modèles, ils entrent dans le modèle, tandis que dans d’autres, ils sont inclus dans le contrôleur. Mais je pense qu’il est préférable de les garder avec le contrôleur. Laissez le modèle s’inquiéter uniquement de la connectivité de la firebase database.