web-dev-qa-db-fra.com

ASP.NET MVC - La logique métier doit-elle exister dans les contrôleurs?

Derik Whitaker a publié il y a quelques jours un article qui a touché un point qui m'intéresse depuis un certain temps: la logique métier devrait-elle exister dans les contrôleurs?

Jusqu'à présent, toutes les démos ASP.NET MVC que j'ai vues mettent l'accès au référentiel et la logique métier dans le contrôleur. Certains y ajoutent même une validation. Il en résulte des contrôleurs assez volumineux et gonflés. Est-ce vraiment la façon d'utiliser le framework MVC? Il semble que cela va se retrouver avec beaucoup de code et de logique dupliqués répartis sur différents contrôleurs.

asp.net-mvcdesign-patternscontrollerbusiness-logic
96
Kevin Pang

La logique métier devrait vraiment être dans le modèle. Vous devriez viser des modèles gras, des contrôleurs maigres.

Par exemple, au lieu d'avoir:

public interface IOrderService{
    int CalculateTotal(Order order);
}

Je prefererais avoir:

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

Cela suppose que la taxe est calculée par un service externe et nécessite que votre modèle connaisse les interfaces avec vos services externes.

Cela ferait ressembler votre contrôleur à quelque chose comme:

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

Ou quelque chose comme ça.

75
jonnii

J'aime le diagramme présenté par Microsoft Patterns & Practices . Et je crois en l'adage "Une image vaut mille mots".

Diagram shows architecture of MVC and business sevices layers

63
AlejandroR

Vous pouvez consulter ce tutoriel génial de Stephen Walther qui montre Validation avec une couche de service .

Découvrez comment déplacer votre logique de validation des actions de votre contrôleur vers une couche de service distincte. Dans ce didacticiel, Stephen Walther explique comment maintenir une séparation nette des problèmes en isolant votre couche de service de votre couche de contrôleur.

14
Leniel Maccaferri

C'est une question fascinante.

Je pense qu'il est intéressant qu'un grand nombre d'exemples d'applications MVC ne parviennent pas à suivre le paradigme MVC dans le sens de vraiment placer la "logique métier" entièrement dans le modèle. Martin Fowler a souligné que MVC n'est pas un modèle au sens du Gang Of Four. Au contraire, c'est un paradigme que le programmeur doit ajouter des modèles à s'il crée quelque chose au-delà d'une application de jouet.

Donc, la réponse courte est que la "logique métier" ne devrait en effet pas vivre dans le contrôleur, car le contrôleur a la fonction supplémentaire de gérer la vue et les interactions utilisateur et nous voulons créer des objets avec un seul objectif.

Une réponse plus longue est que vous devez réfléchir à la conception de votre couche de modèle avant de simplement déplacer la logique du contrôleur au modèle. Vous pouvez peut-être gérer toute la logique des applications à l'aide de REST, auquel cas la conception du modèle devrait être assez claire. Sinon, vous devez savoir quelle approche vous allez utiliser pour éviter que votre modèle ne se gonfle.

14
Joe Soul-bringer

Business Logic ne doit pas être contenu dans les contrôleurs. Les contrôleurs doivent être aussi maigres que possible, suivez idéalement le bagout:

  1. Rechercher une entité de domaine
  2. Agir sur l'entité de domaine
  3. Préparer les données pour afficher/renvoyer les résultats

De plus, les contrôleurs peuvent contenir une logique d'application.

Alors, où dois-je mettre ma logique métier? Dans le modèle.

Qu'est-ce que le modèle? Voilà une bonne question. Veuillez consulter article Microsoft Patterns and Practices (bravo à AlejandroR pour une excellente recherche). Ici, il existe trois catégories de modèles:

  • Afficher le modèle : il s'agit simplement d'un sac de données, avec une logique minimale, le cas échéant, pour transmettre des données depuis et vers les vues, contient une validation de base du champ.
  • Modèle de domaine : modèle Fat avec logique métier, opère sur une ou plusieurs entités de données (c'est-à-dire l'entité A dans un état donné que l'action sur l'entité B)
  • Modèle de données : modèle sensible au stockage, la logique contenue dans une seule entité ne se rapporte qu'à cette entité (c'est-à-dire si le champ a puis le champ b)

Bien sûr, MVC est un paradigme qui se décline en différentes variétés. Ce que je décris ici est MVC occupant uniquement la couche supérieure, vide cet article sur Wikipedia

Aujourd'hui, MVC et MVP (Model-View-Presenter) sont des modèles de conception de séparation des préoccupations qui s'appliquent exclusivement à la couche de présentation d'un système plus grand. Dans des scénarios simples, MVC peut représenter la conception principale d'un système, atteignant directement la base de données; cependant, dans la plupart des scénarios, le contrôleur et le modèle dans MVC ont une dépendance lâche sur une couche ou un niveau de service ou de données. Il s'agit de l'architecture client-serveur

8
Jacek Glen