La logique métier doit-elle être dans le modèle? (MVC4)

Question

J'ai une classe appelée "Stores" dans mon application MVC qui a une classe appelée "IsInCompliance" qui dépend des valeurs de plusieurs autres champs. La logique passerait par et dirait "si ceci, ceci, et ceci est vrai, alors IsInCompliance est vrai".

Devrait-il appartenir à la définition du modèle, ou cette logique serait-elle mieux placée dans une couche de service ou un contrôleur? Je me dis que j'ai quatre options:

1. Logic contenu dans une méthode dans le modèle
2. Logic contenu dans un contrôleur qui écrit de retour au modèle
3. Logic contenu dans un service que le modèle appelle
4. Logique contenue dans un service que le contrôleur appelle

Quel est le meilleur? Si 3 est le meilleur, n'y a-t-il pas une dépendance circulaire (puisque mon projet de modèle dépend du projet de services, qui dépend du projet de modèle)?

Answer 1

Le numéro 4 est la bonne approche. Les contrôleurs doivent agir comme une fine couche de «contrôle du trafic» et déléguer toute la logique à une couche de service sous-jacente (ou si la logique n'est pas trop évidente pour une couche de gestion, mais c'est une question architecturale différente).

Votre modèle doit généralement être une structure POCO pure, avec éventuellement une micro-logique de choses internes au modèle de données. Par exemple, génération d'ID et opérations d'intégrité des données.

La plupart de votre logique (pour les applications relativement simples/basées sur CRUD) devrait généralement se trouver dans la couche Service.

Answer 2

Ceci est une question de préférence/style, mais j'ai toujours cru que les méthodes qui sont pertinentes à l'objet Modèle appartiennent à cet objet.

Prenez cela comme un exemple (je codage à la volée sans une instance de VS.NET ouverte, donc s'il vous plaît pardonnez les erreurs de syntaxe, juste essayer de l'utiliser comme un moyen de communication):

public class Person 
{ 
    public Int32 Age { get; set; } 

    public bool IsEligibleToEnterLegallyBindingContract() 
    { 
     return Age >= 18; 
    } 
} 

Je voudrais affirmer qu'un objet modèle qui contient des méthodes qui introspecte ses propres propriétés et ne dépend pas des messages et/ou des propriétés d'autres objets de modèle est une bonne conception d'objet et une bonne approche de modélisation dans un environnement MVC.

Mise à jour J'ai eu une discussion avec un collègue à ce sujet, et il m'a dirigé vers le Anemic Domain Model, un excellent article de Martin Fowler. J'ai lu cet article plusieurs fois après que mon collègue l'eut recommandé.

Le dernier paragraphe de l'article de M. Fowler (ce qui est une citation directe de martinfowler.com et le crédit est reconnu et donné à ce site):

« En général, plus vous trouverez le comportement dans les services Plus vous avez de chances de vous priver des avantages d'un modèle de domaine, si votre logique est dans les services, vous vous êtes volé à l'aveugle.

Answer 3

MVC consiste à séparer les préoccupations. Continue comme ça.Séparez votre logique de vos données en plaçant votre logique métier dans une classe distincte (couche).

Answer 4

Habituellement, j'effectue des actions sur le modèle plutôt que sur le modèle, mais c'est une sorte de préférence personnelle. Je voudrais (dans votre cas) écrire la logique dans la couche Service, puis faire un appel de coordination à partir du contrôleur qui fonctionnerait sur le modèle. Cela dit, je crois que certaines personnes se réfèrent à cela comme Anemic Domain Model.

Je ne pense pas que l'une des approches sont erronées, mais personnellement, je pencherais pour le numéro 4.

Answer 5

Je suppose que cela dépend de votre style de codage.

L'option 1 ou l'option 4 est correcte en fonction de la personne à contacter.

Pour quelque chose comme ça, je pense que l'option 1 est correcte.

Si IsInCompliance dépend uniquement de la valeur d'autres propriétés dans le modèle, il doit être dans le modèle.

Si la valeur de IsInCompliance dépend d'autres classes, alors oui, elle devrait l'être dans une couche de service.

mouvement des trucs comme ça à un résultat de la couche de service dans un modèle de domaine où Anemic vos classes de modèle finissent par être juste

de DTO

Dans la conception orientée objet, cela est considéré comme un modèle de lutte contre.

Il y a encore beaucoup de choses qui doivent être dans une couche de service, je ne pense pas que ce soit l'un d'entre eux.