D'où vient la « couche logique métier » adapter à une application MVC?

Question

Tout d'abord, avant que quelqu'un de dupe, j'ai eu du mal à le résumer dans un simple titre. Un autre titre aurait été « Quelle est la différence entre un modèle de domaine et le modèle MVC? » ou « Qu'est-ce qu'un modèle? »

Conceptuellement, je comprends un modèle à les données utilisées par les vues et contrôleur. Au-delà, il semble y avoir beaucoup d'opinions divergentes sur ce qui fait le modèle. Qu'est-ce qu'un modèle de domaine, par rapport à un modèle d'application, contre un modèle de vue, contre un modèle de service, etc ..

Par exemple, dans une question récente je leur ai demandé le modèle référentiel, on m'a dit que le but en blanc référentiel fait partie du modèle. Cependant, j'ai lu d'autres opinions que le modèle doit être séparé du modèle de persistance et la couche logique métier. Après tout, n'est pas le modèle du référentiel supposé découpler la méthode de persistance du béton à partir du modèle? D'autres personnes disent qu'il ya une différence entre le modèle de domaine et le modèle MVC.

Prenons un exemple simple. Le AccountController qui est inclus dans le projet par défaut MVC. J'ai lu plusieurs avis que le code de compte inclus est de mauvaise conception constitue une violation SRP, etc .. etc .. Si on devait concevoir un modèle d'adhésion « appropriée » pour une application MVC, quelle serait?

Comment qualifieriez-vous les services de séparer ASP.NET (fournisseur d'adhésion, fournisseur de rôles, etc ..) à partir du modèle? Ou voulez-vous du tout?

La façon dont je le vois, le modèle devrait être « pur », peut-être avec la logique de validation .. mais doit être séparé de règles métier (autres que la validation). Par exemple, disons que vous avez une règle métier qui dit que quelqu'un doit être envoyé par courrier électronique lorsqu'un nouveau compte est créé. Cela n'appartient pas vraiment dans le modèle à mon avis. Alors, où appartient-il?

Quelqu'un veut faire la lumière sur cette question?

Answer 1

La façon dont je l'ai fait - et je ne dis pas qu'il est bon ou mauvais, est d'avoir mon point de vue et un modèle applicable à mon avis. Ce modèle ne dispose que ce qui est pertinent à mon avis - y compris les annotations de données et les règles de validation. Le contrôleur logique héberge uniquement pour la construction du modèle. J'ai une couche de service qui abrite toute la logique métier. Mes contrôleurs appellent ma couche de service. Au-delà de ce qui est ma couche dépôt.

Mes objets de domaine sont logés séparément (dans leur propre projet, en fait). Ils ont leurs propres annotations de données et les règles de validation. Mon dépôt valide les objets dans mon domaine avant de les enregistrer dans la base de données. Parce que chaque objet dans mon domaine hérite d'une classe de base qui a construit la validation, mon référentiel est tout générique et valide (et exige hérite de la classe de base).

On pourrait penser que d'avoir deux séries de modèles est la duplication de code, et il est dans une certaine mesure. Mais, il y a des cas parfaitement raisonnables où l'objet de domaine ne convient pas pour la vue.

cas au point est lorsque l'on travaille avec des cartes de crédit - Je dois exiger un CVV lors d'un paiement, mais je ne peux pas stocker le CVV (il est une amende 50 000 $ pour le faire). Mais, je veux aussi que vous pourrez modifier votre carte de crédit - changement d'adresse, le nom ou la date d'expiration. Mais tu ne vas pas me donner le numéro ou le CVV lors de l'édition, et je ne suis certainement pas allez mettre votre numéro de carte de crédit en texte clair sur la page. Mon domaine a ces valeurs requises pour l'enregistrement d'une nouvelle carte de crédit parce que vous leur donnez à moi, mais mon modèle d'édition ne comprend même pas le numéro de carte ou CVV.

Un autre avantage à tant de couches est que si architecturé correctement, vous pouvez utiliser StructureMap ou un autre récipient et IoC échange des morceaux sans nuire à votre application.

À mon avis, le code du contrôleur ne doit être ciblé le code à la vue. Montrer ce, cacher, etc. La couche de service devrait abriter la logique métier pour votre application. Je aime avoir tout cela en un seul endroit il est donc facile de changer ou de modifier une règle métier. La couche dépôt doit être relativement muet - dépourvu de logique métier et seulement interroger vos données et retourner vos objets de domaine. En séparant les modèles de vue du modèle de domaine, vous avez beaucoup plus de flexibilité en matière de règles de validation personnalisée. Cela signifie également que vous ne devez pas vider chaque morceau de données dans votre point de vue dans les champs cachés et repoussez-et-vient entre le client et le serveur (ou le reconstruire sur le back-end). Votre modèle de vue alors que loger les informations pertinentes à la vue - et il peut être personnalisé pour avoir bools pour une logique de vue ou compte ou énumérations de sorte que la vue elle-même ne soit pas encombré avec les états logiques complexes comme

<% if (!String.IsNullOrEmpty(Model.SomeObject.SomeProperty) && 
    Model.SomeObject.SomeInt == 3 && ...) { %>

Alors que tout semble étendu et sur-couches, il a un but d'être architecturé de cette façon. Est-il parfait? pas vraiment. Mais je préfère à certains modèles passés de l'appel des dépôts du contrôleur et ayant une logique métier mélangé dans le contrôleur, le dépôt et le modèle.

Answer 2

Je me demandais trop souvent comment exactement les éléments MVC remplirait un espace d'application web traditionnelle, où vous avez vues (pages), des contrôleurs, des services et des objets de données (modèle). Comme vous l'avez dit, il existe de nombreuses versions de cela.

Je crois que la confusion existe en raison de l'architecture, largement acceptée ci-dessus indiqué, qui utilise le « modèle de domaine anémique » (présumé) de modèle -anti. Je ne vais pas entrer dans les détails beaucoup sur les « anti-patternness » du modèle de données anémiques (vous pouvez regarder un effort de mine pour expliquer les choses ici (Java, mais pertinent pour toutes les langues) ). Mais en bref, cela signifie que notre modèle contient uniquement les données et la logique métier est placé dans les services / gestionnaires.

Mais supposons que nous avons architecture orientée domaine , et nos objets de domaine sont la manière ils devraient être - ayant à la fois l'état et la logique métier. Et dans ces choses perspective axée sur domaine sont en place:

• la vue est l'interface utilisateur
• le contrôleur fronces les entrées de l'interface utilisateur, les méthodes de Invoque sur le modèle, et renvoie une réponse à l'interface utilisateur
• le modèle est nos composants métier -. Contenant les données, mais aussi avoir la logique métier

Je suppose que vos réponses aux questions principales. Les choses se compliquent quand on ajoute des couches plus, comme la couche de stockage. Il est souvent suggéré qu'il devrait être invoqué par la logique métier placée dans le modèle (et donc chaque objet de domaine a une référence à un référentiel). Dans l'article de mes que je soutiens que je lié ce n'est pas tout à fait une meilleure pratique. Et qu'en fait, ce n'est pas une mauvaise chose d'avoir une couche de service. Soit dit en passant, la conception pilotée par le domaine n'exclut pas la couche de service, mais il est censé être « mince », et que la coordination des objets de domaine (donc pas de logique métier là-bas).

Pour le paradigme du modèle de données anémique, ce qui est largement adopté (pour le bien ou pour le mal), le modèle serait à la fois la couche de service et vos objets de données.

Answer 3

A mon avis,

Modèle -

ne doivent pas contenir la logique métier, il devrait être connectables (WCF comme scénario). Il est utilisé pour se lier à voir, il devrait avoir des propriétés.

Business Logic -

Il doit être placé à « couche des services de domaine », il est tout à fait distincte couche. En outre, ajoutera une couche supplémentaire ici "Application Services".

parle App Services aux services de domaine couche pour appliquer la logique métier, puis revenir enfin le modèle.

Alors, Contrôleur demandera application de service pour le modèle et le flux sera comme,

    Controller->Application Services(using domain services)->Model

Answer 4

Le modèle MVC et le cadre Asp.net ne fait aucune distinction sur ce que le modèle devrait être.

propres exemples de MS comprennent la persistance des classes dans le modèle. Votre question sur l'adhésion étant dans le modèle. Cela dépend. Sont classes dans votre modèle appartiennent à quelque chose? Y at-il un lien entre ceux qui se connectent et quelles données sont affichées? Y at-il une partie de filtrage de données d'un système d'autorisations qui est modifiable? Est qui dernière mise à jour ou modifié une partie de l'objet de votre domaine comme dans quelqu'un d'autre a besoin de le voir ou quelque chose pour le soutien de back-end?

L'exemple de courrier électronique est aussi dépend. Êtes-vous familier avec le domaine concours complet ou concours complet en particulier? Avez-vous un service distinct pour envoyer des emails? Le fait d'envoyer une partie e-mail de votre domaine ou est-il un problème au niveau des applications en dehors de la portée de votre système? Le besoin de l'interface utilisateur de savoir si un courriel a été envoyé avec succès ou non? Faites des e-mails qui ne parviennent pas à envoyer des relances de besoin? Le contenu de la nécessité email SENT à stocker pour support ou les exigences de service à la clientèle?

Ces types de questions sont trop large et subjective, mais je vous répondre si et tout le monde qui vous a voté en peut comprendre.

Vos besoins / délais / toutes les ressources ressuage dans l'architecture de votre système. Même le modèle de revenus peut avoir un effet. Vous devez également considérer le modèle que vous filmez pour. DDD est bien différent que les applications persistance comme modèle et tous les slops entre sont également valables pour certaines applications. Tirez-vous pour tester l'application? Tout cela a un effet.