Logique d'entreprise dans MVC

j'ai 2 questions:

Q1. Où se trouve exactement la "logique commerciale" dans le modèle MVC? Je confonds Modèle et contrôleur.

Q2. Est "logique d'entreprise" les mêmes "règles métier"? Si non, quelle est la différence?

Ce serait génial si vous pouviez expliquer avec un petit exemple.

144
demandé sur Md. Abu Nafee Ibna Zahid 2010-12-11 11:32:37
la source

9 ответов

règles d'Entreprise vont dans le modèle.

dites que vous affichiez 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 le modèle pour supprimer l'entrée N, Puis notifie la vue que le modèle a changé.

peut-être que le courriel de l'administrateur ne devrait jamais être retiré de la liste. C'est une règle d'affaires, que la connaissance appartient au modèle. La vue peut finalement représenter cette règle en quelque sorte -- peut - être que le modèle expose une propriété "IsDeletable" qui est une fonction de la règle d'affaires, de sorte que le bouton Supprimer 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 ultimement gatekeeper pour vos données. Vous devriez être en mesure de tester votre logique métier sans toucher à l'INTERFACE utilisateur.

144
répondu Mud 2014-07-02 19:23:50
la source

Poing de tous:

Je crois que vous mélangez le modèle MVC et les principes de conception basés sur n-tier.



Utiliser une approche MVC ne signifie pas que vous ne devriez pas caler votre application.

Cela pourrait aider si vous voyez MVC plus comme une extension de la couche de présentation.



Si vous mettez le code de non-présentation à l'intérieur du modèle MVC vous pourriez très bientôt dans un design compliqué.

Par conséquent, je suggère que vous mettez votre logique d'affaires dans une couche d'affaires séparée.

regardez juste ceci: article de Wikipedia sur l'architecture multitier



Aujourd'hui, MVC et similaire model-view-presenter (MVP) sont une séparation des préoccupations dessins qui s'appliquent exclusivement à la couche de présentation d'un système plus grand.

en tout cas ... quand on parle d'une application web d'entreprise les appels de L'UI à la couche logique d'affaires devraient être placés à l'intérieur du contrôleur (présentation).



C'est parce que le controller gère effectivement les appels à une ressource spécifique, les données en faisant des appels à la logique d'affaires et relie les données (modèle) à la vue appropriée.



La boue vous a dit que les règles vont dans le modèle.

C'est également vrai, mais il a confondu le modèle (de présentation) (le " M " dans MVC) et le modèle de la couche de données d'une conception d'application par niveau.

Ainsi, il est valide de placer votre base de données activités liées règles dans le modèle (data layer) 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 de wheather vous utilisez une conception par domaine ou une approche basée sur un script de transaction.



Laisse-moi visualiser ça pour toi.:




couche de présentation: Model-View-Controller


couche Métier: Domaine de la logique - la logique de l'Application


couche de données: dépôts 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 commune pour concevoir une plus grande application web d'entreprise.



Mais vous pouvez aussi concentrer l'utilisation d'un simple non-DDD couche (la couche sans logique de domaine) et une simple couche de données qui écrit directement à une base de données spécifique.

Vous pouvez même laisser tomber toute la couche de données et accéder à la base de données directement à partir de la couche affaires, bien que je ne le recommande pas.



C'est " le truc...J'espère que cette 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 vue spécifique, mais souvent indépendants des contrôles. La couche business peut aussi avoir un modèle, appelé "domain-model". C'est généralement le cas lorsque vous décidez de prendre un approche axée sur le domaine. Ce "domaine-modèle" contient des données ainsi que la logique d'entreprise (la logique principale de votre programme) et est généralement indépendant de la couche de présentation. La couche présentation appelle habituellement la couche affaires sur un certain "événement" (bouton appuyé etc.) pour lire des données ou écrire des données dans la couche de données. La couche de données peut aussi avoir son propre modèle, qui est typiquement relié à une base de données. Il contient souvent un ensemble de classes entity ainsi que des données-access-objects (DAOs).

la question est: comment cela s'inscrit-il dans le concept MVC?

réponse - > ce n'est pas le cas!

Bien - il 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. À cette époque, les interfaces graphiques et les ordinateurs personnels étaient assez rares et le World wide web n'a même pas été inventé! La plupart des langages de programmation et L'IDEs a été créé dans les années 1990. À cette époque, les ordinateurs et les interfaces utilisateurs étaient complètement différents de ceux des années 1970.

Tu devrais garder ça à l'esprit quand tu parles de MVC.

Martin Fowler a écrit un très bon article sur MVC, MVP et les interfaces graphiques d'aujourd'hui.

146
répondu Frank 2016-11-12 03:54:15
la source

le terme logique commerciale n'est pas, à mon avis, une définition précise. Evans parle dans son livre, Domain Driven Design, de deux types de logique d'affaires:

  • Domaine de la logique.
  • la logique de l'Application.

Cette séparation est à mon avis beaucoup plus clair. Et avec la réalisation qu'il y a différents types de règles d'affaires vient aussi la réalisation qu'ils ne vont pas nécessairement tous la même lieu.

la logique de domaine est la 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 affectations, la fiscalité, etc. Dans un outil de planification de logiciel agile, les règles seraient des trucs comme calculer les dates de publication en fonction de la vitesse et des points d'histoire dans l'arriéré, etc.

pour ces deux types d'application, CSV import / export pourrait être pertinent, mais les règles de CSV importation/exportation n'a rien à voir avec le domaine. Ce genre de logique est la logique d'application.

la logique du domaine va très certainement dans la couche modèle. Le modèle correspondrait également à la couche domaine dans DDD.

Toutefois, la logique D'Application

ne doit pas nécessairement être placée dans la couche modèle. Cela pourrait être placé dans les controllers directement, ou vous pourriez créer une couche application distincte hébergeant ces règles. Ce qui est le plus logique ce cas dépendra de l'application réelle.

65
répondu Pete 2011-08-28 20:40:38
la source

A1 : la Logique d'Entreprise va à Model dans le cadre MVC . Le rôle de Model est de contenir des données et une logique commerciale. Controller d'un autre côté est responsable de recevoir la contribution 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 .

regardez Wikipedia entry for MVC . Allez à Aperçu où il mentionne le flux de MVC modèle.

regardez aussi Wikipedia entry for Business Logic . Il est indiqué que Business Logic comprend Business Rules et Workflow .

22
répondu decyclone 2012-11-30 14:21:01
la source

c'est une question à laquelle on répond, Mais je vais donner mon "Un cent":

règles Commerciales appartiennent dans le modèle. Le" modèle "consiste toujours en (séparés logiquement ou physiquement):

  • modèle de présentation - un ensemble de classes qui est bien adapté à l'utilisation dans la vue (il est adapté à L'UI spécifique/présentation),
  • modèle de domaine - l'INTERFACE utilisateur indépendant de la partie de le modèle, et
  • dépôt - la partie du "modèle" qui est axée sur le stockage.

règles d'Entreprise de vivre dans le modèle du domaine, sont exposés dans une présentation-forme appropriée pour la "présentation" modèle et sont parfois dupliquées (ou forcée) dans la "couche de données".

11
répondu G. Stoynev 2013-07-15 07:45:00
la source

comme quelques réponses l'ont souligné, je crois qu'il y a une certaine incompréhension entre l'architecture multi-niveaux et MVC.

l'architecture à niveaux multiples consiste à fractionner votre application en niveaux/couches (par exemple, présentation, logique opérationnelle, 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 commerciale/les règles commerciales/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 commerciale dans votre couche de présentation et donc à réduire la réutilisation et la maintenabilité de votre code.

le modèle est un choix de choix très raisonnable pour placer la logique d'affaires, mais une approche meilleure/plus maintenable est de séparer votre couche de présentation de votre couche de logique d'affaires et de créer une couche de logique d'affaires et appelez simplement la couche de logique d'affaires de vos modèles lorsque nécessaire. La logique métier layer 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élange la logique commerciale et l'accès aux données dans l'un des composants MVC, surtout si l'application n'a pas été construite en utilisant plusieurs niveaux. Cependant, dans la plupart des applications d'entreprise, vous trouverez généralement des architectures multi-niveaux avec une architecture MVC en place dans la couche de présentation.

5
répondu treefiddy 2017-08-25 16:13:02
la source

il n'est pas logique de mettre votre couche d'affaires dans le modèle pour un projet MVC.

dites que votre patron décide de changer la couche de présentation en quelque chose d'autre, vous seriez foutu! La couche "affaires" devrait être une assemblée distincte. Un Modèle contient les données provenant de la couche de gestion qui passe à la vue à afficher. Puis sur post par exemple, le modèle se lie à une classe de personne qui réside dans la couche d'affaires et appelle PersonBusiness.SavePerson(p); où p est la classe des personnes. Voici ce que je fais (Classe BusinessError est absent, mais serait aller dans le business layer aussi): enter image description here

3
répondu Alex 2017-02-03 21:44:59
la source

T1:

logiques d'Entreprise peut être envisagée dans deux catégories:

  1. Domaine logiques comme les contrôles sur une adresse de courriel (unicité, contraintes, etc.), en obtenant le prix d'un produit à facturer, ou en calculant le prix total de shoppingCart en fonction de ses objets de produit.

  2. flux de travail plus larges et plus compliqués que l'on appelle processus d'affaires, comme le contrôle le processus d'inscription de l'étudiant (qui comprend généralement plusieurs étapes et nécessite des vérifications différentes et a des contraintes plus compliquées).

Le première "1519160920 catégorie" va dans modèle et le deuxième un appartient à contrôleur . Cela s'explique par le fait que les cas de la deuxième catégorie sont des logiques d'application Générales et que leur inclusion dans le modèle peut mélanger l'abstraction du modèle (par exemple, il n'est pas clair si nous devons mettre ces décisions dans une classe de modèle ou une autre, car elles sont liées aux deux!).

voir ce 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 point est que les notes mentionnées par " boue" et "franc" au-dessus des deux peut être vrai aussi bien que "Pete"s (business logic peut être mis dans le modèle, ou contrôleur, selon le type de business logic).

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 ce post par exemple).


Q2:

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

règles d'entreprise pour les petites entreprises

1
répondu Alisa 2017-05-23 14:54:56
la source

Modèle = code pour CRUD opérations de base de données.

Controller = répond aux actions de l'utilisateur et transmet les demandes de récupération de données ou de suppression/mise à jour au modèle, sous réserve des règles commerciales spécifiques à une organisation. Ces règles de gestion pourraient être mises en œuvre dans les classes helper, ou si elles ne sont pas trop complexes, directement dans les actions du contrôleur. Le contrôleur demande enfin à la vue de se mettre à jour afin de donner un feedback à l'utilisateur sous la forme de un nouvel affichage,ou un message comme 'updated, thanks', etc.,

View = UI généré à partir d'une requête sur le modèle.

il n'y a pas de règles strictes quant à l'orientation des règles commerciales. 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 est préférable de les garder avec le contrôleur. Laissez le modèle s'occuper uniquement de la connectivité de la base de données.

-5
répondu Hoven 2013-03-17 09:34:03
la source