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

Question

Derik Whitaker a publié un article il y a quelques jours qui a frappé un point que j'ai été curieux depuis un certain temps: la logique métier doit-elle exister dans les contrôleurs?

Jusqu'à présent, toutes les démonstrations ASP.NET MVC que j'ai vues ont mis l'accès au référentiel et la logique métier dans le contrôleur. Certains y jettent même une validation. Cela se traduit par des contrôleurs assez volumineux et gonflés. Est-ce vraiment la manière d'utiliser le framework MVC? Il semble que cela va se solder par de nombreuses duplications de code et de logique réparties sur différents contrôleurs.

Answer 1

La logique métier doit vraiment figurer dans le modèle. Vous devriez viser les gros modèles, les contrôleurs minces.

Par exemple, au lieu d'avoir:

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

Je préférerais avoir:

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

Cela suppose que la taxe est calculée par un service externe et que votre modèle doit connaître les interfaces avec vos services externes.

Cela donnerait à 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.

Answer 2

J'aime le diagramme présenté par Microsoft Patterns & amp; Pratiques . Et je crois en l'adage «Une image vaut mille mots».

Answer 3

C'est une question fascinante.

Je pense qu'il est intéressant de noter qu'un grand nombre d'exemples d'applications MVC ne parviennent pas à suivre le paradigme MVC dans le sens de placer véritablement 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. Il est plutôt paradigmatique que le programmeur doive ajouter des modèles à s’il crée quelque chose au-delà d’une application jouet.

La réponse courte est donc que " la logique métier " ne devrait en effet pas résider dans le contrôleur, car celui-ci a pour fonction supplémentaire de gérer les interactions vue / utilisateur et nous voulons créer des objets dans un seul but.

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 vers le modèle. Vous pouvez peut-être gérer toute la logique de l'application à l'aide de REST, auquel cas la conception du modèle devrait être assez claire. Sinon, vous devriez savoir quelle approche vous allez utiliser pour éviter que votre modèle ne soit gonflé.

Answer 4

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

  

Découvrez comment déplacer votre validation   logique de vos actions de contrôleur   et dans une couche de service séparée. Dans   ce tutoriel, Stephen Walther   explique comment vous pouvez maintenir une forte   séparation des préoccupations en isolant   votre couche de service de votre   couche contrôleur.

Answer 5

La logique applicative ne doit pas être contenue dans les contrôleurs. Les contrôleurs doivent être aussi minces que possible et suivre idéalement le modèle:

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

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

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

Qu'est-ce qu'un modèle? Maintenant c'est une bonne question. Consultez l'article Patterns and Practices de Microsoft (félicitations à AlejandroR pour son excellente trouvaille). Ici, il existe trois catégories de modèles:

• Modèle de vue : il s'agit simplement d'un conteneur de données, avec une logique minimale, le cas échéant, pour la transmission de données depuis et vers des vues, qui contient une validation de base des champs.
• Modèle de domaine : modèle Fat avec logique métier, fonctionne sur une ou plusieurs entités de données (c'est-à-dire l'entité A dans un état donné plutôt que l'action sur l'entité B)
• Modèle de données : modèle prenant en compte le stockage, la logique contenue dans une seule entité ne concerne que cette entité (c'est-à-dire si les champs a et ensuite b)

Bien entendu, MVC est un paradigme qui se décline en différentes variétés. Ce que je décris ici, c’est que MVC n’occupe que la couche supérieure, voir cet article sur Wikipedia

.

  

Aujourd'hui, MVC et les modèles de vue-présentation (MVP) similaires sont des modèles de conception de séparation des problèmes 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 libre sur un niveau / couche de service ou de données. C’est une question d’architecture client-serveur

Answer 6

Si vous utilisez des injecteurs de dépendance, votre logique d’affaires les utilisera et vous obtiendrez ainsi des contrôleurs propres et ordonnés.