J'ai deux questions :
Q1. Où se situe exactement la "logique métier" dans le modèle MVC ? Je ne comprends pas bien la différence entre le modèle et le contrôleur.
Q2. La "logique d'entreprise" est-elle la même chose que les "règles d'entreprise" ? Si ce n'est pas le cas, quelle est la différence ?
Ce serait bien si vous pouviez m'expliquer avec un petit exemple.
Le premier de tous :
Je pense que vous mélangez le modèle MVC et les principes de conception basés sur les n-tiers.
L'utilisation d'une approche MVC ne signifie pas que vous ne devez pas superposer des couches dans votre application.
Il peut être utile de considérer MVC comme une extension de la couche de présentation.
Si vous placez du code non lié à la présentation à l'intérieur du modèle MVC, vous risquez très vite de vous retrouver avec une conception compliquée.
C'est pourquoi je vous suggère de placer votre logique d'entreprise dans une couche d'entreprise distincte.
Il suffit de jeter un coup d'œil à ceci : Article de Wikipédia sur l'architecture multi-niveaux
Il est écrit :
Aujourd'hui, le MVC et les modèles similaires de type modèle-vue-présentateur (MVP) sont des modèles de séparation des préoccupations qui s'appliquent exclusivement à l'interface utilisateur. couche de présentation d'un système plus large.
Quoi qu'il en soit, lorsque l'on parle d'un application web d'entreprise les appels de l'interface utilisateur à la logique métier doivent être placés dans le contrôleur (de présentation).
En effet, le contrôleur gère les appels à une ressource spécifique, interroge les données en faisant appel à la logique commerciale et relie les données (modèle) à la vue appropriée.
Mud vous a dit que les règles de gestion sont intégrées dans le modèle.
C'est également vrai, mais il a confondu le modèle (de présentation) (le "M" de MVC) et le modèle de la couche de données d'une conception d'application basée sur des niveaux.
Il est donc valable de placer votre entreprise liée à la base de données règles 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 en MVC, car cela ne s'applique qu'à une interface utilisateur spécifique.
Cette technique est indépendante de l'utilisation d'une conception axée sur le domaine ou d'une approche basée sur des script de transaction.
Permettez-moi de visualiser cela pour vous :
Couche de présentation : Modèle - Vue - Contrôleur
Couche commerciale : Logique du domaine - Logique de l'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 la conception d'une application web d'entreprise de grande envergure.
Mais vous pouvez aussi le réduire à une simple couche métier non DDD (une couche métier 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 abandonner 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.
[Note :] Vous devez également être conscient du fait qu'il existe aujourd'hui plus d'un "modèle" dans une application. En général, chaque couche d'une application possède 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 métier peut également disposer d'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 qu'une logique commerciale (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 métier lors d'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 objets d'accès aux données (DAO).
La question est la suivante : comment cela s'intègre-t-il dans le concept MVC ?
Réponse -> Ce n'est pas le cas !
En fait, 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 peu courants et le World Wide Web n'avait même pas encore été 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 d'aujourd'hui.
+1 pour avoir correctement listé la différence entre mvc et n-tier app. La plupart des applications d'entreprise que je développe sont n-tiers et utilisent mvc comme couche de présentation uniquement.
Disons que 1) les modèles de vue en MVC (couche présentation) 2) certaines technologies C# (couche métier) pour les transactions autorisées, la logique des règles métier de base. 3) Référentiel et unité de travail dans (couche d'accès aux données) Veuillez nous indiquer quelques technologies (ou modèles de meilleures pratiques) qui peuvent être utilisées pour construire la couche métier qui devrait être libre d'autoriser et d'exposer le modèle, le référentiel pour accéder au contrôleur dans la couche de présentation (couche supérieure). Fondamentalement, je pense que l'ajout, la suppression, la mise à jour et sa combinaison sont de la logique commerciale et devraient être conservés dans les transactions. Merci de m'éclairer sur ce point.
Bonjour Rahul, si je vous comprends bien, vous avez raison. Les opérations CRUD sont fondamentalement des parties atomiques des transactions commerciales. Personnellement, je préfère utiliser un puissant OR mapper comme Hibernate en tant que référentiel plutôt que de construire mon propre référentiel. En effet, Hibernate implémente déjà le modèle d'unité de travail en interne. De plus, je place généralement les transactions commerciales dans des services commerciaux distincts.
Les règles de gestion se trouvent dans le modèle.
Supposons que vous affichiez des courriels pour une liste de diffusion. L'utilisateur clique sur le bouton "supprimer" à côté de l'un des courriels, le contrôleur notifie au modèle de supprimer l'entrée N, puis notifie à la vue que le modèle a changé.
Peut-être que l'adresse électronique de l'administrateur ne devrait jamais être supprimée de la liste. Il s'agit d'une règle de gestion, et 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 - peut-être que le modèle expose une propriété "IsDeletable" qui est une fonction de la règle de gestion, 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 en fin de compte le gardien de vos données. Vous devriez pouvoir tester votre logique commerciale sans toucher à l'interface utilisateur.
Merci pour cet exemple. Pour l'entrée de l'email de l'administrateur (contrôler s'il peut être supprimé ou non), ne pouvons-nous pas contrôler cela en utilisant notre contrôleur ?
@mud et si nous divisions 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 commerciale et le référentiel est responsable de la couche de données... ?
Le terme "logique d'entreprise" n'est pas, à mon avis, une définition précise. Evans parle dans son livre, Domain Driven Design, de deux types de logique d'entreprise :
Cette séparation est à mon avis beaucoup plus claire. En réalisant qu'il existe différents types de règles de gestion, on se rend également compte qu'elles ne vont pas nécessairement toutes au même endroit.
La logique de domaine est la logique qui correspond au domaine réel. Ainsi, si vous créez une application comptable, les règles du domaine seront les règles concernant les comptes, les écritures, la fiscalité, etc. Dans un outil de planification de logiciel agile, les règles seraient des choses comme le calcul des dates de sortie basées sur la vélocité et les points d'histoire dans le backlog, etc.
Pour ces deux types d'application, l'importation/exportation de fichiers CSV peut être pertinente, mais les règles d'importation/exportation de fichiers CSV n'ont rien à voir avec le domaine en question. Ce type de logique est une logique d'application.
La logique du domaine se retrouve très certainement dans la couche du modèle. Le modèle correspondrait également à la couche du domaine dans DDD.
La logique d'application ne doit cependant pas nécessairement être placée dans la couche de modèle. Elle peut être placée directement dans les contrôleurs, ou vous pouvez créer une couche d'application séparée qui héberge ces règles. Ce qui est le plus logique dans ce cas dépend de l'application réelle.
C'est tout à fait vrai ! Il y a deux modèles ici : votre modèle de vue et votre modèle de domaine. Je pense qu'il est presque regrettable que la présentation des projets MVC conduise les développeurs novices à croire qu'ils doivent simplement fourrer leur code dans le modèle de vue.
A1 : La logique d'entreprise va à Model partie en MVC . Rôle des Model est de contenir des données et une logique d'entreprise. Controller est quant à lui chargé de recevoir les données de l'utilisateur et de décider de ce qu'il doit faire.
A2 : A Business Rule fait partie de Business Logic . Ils disposent d'un has a relation. Business Logic a Business Rules .
Jetez un coup d'œil à Wikipedia entry for MVC . Allez à la section Vue d'ensemble où il est fait mention du flux de MVC modèle.
Voir aussi Wikipedia entry for Business Logic . Il est mentionné que Business Logic est composé de Business Rules y Workflow .
Il s'agit d'une question à laquelle on a répondu, mais je vais donner mon "one cent" :
Les règles de gestion font partie du modèle. Le "modèle" est toujours constitué de (séparés logiquement ou physiquement) :
Les règles de gestion se trouvent dans le modèle du domaine, sont exposées sous une forme adaptée à la présentation dans le modèle de "présentation" et sont parfois dupliquées (ou également appliquées) dans la "couche de données".
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
