Quelle quantité de logique métier doit exister dans la couche contrôleur?

Parfois, nous avons une logique métier représentée dans le code du contrôleur de nos applications. C'est généralement une logique qui différencie les méthodes à appeler du modèle et / ou les arguments pour les transmettre.

Un autre exemple de ceci est un ensemble de fonctions utilitaires existant dans le contrôleur qui peuvent fonctionner pour formater ou nettoyer les données renvoyées par le modèle, en fonction d'un ensemble de règles de gestion.

Cela fonctionne, mais je me demande s’il flirte avec le désastre. S'il existe une logique métier partagée entre le contrôleur et le modèle, les deux couches ne sont plus séparables et une personne héritant du code peut être déconcertée par cette inégalité de localisation du code associé à la logique métier.

Ma question est la suivante: dans quelle mesure la logique métier doit-elle être autorisée dans le contrôleur et dans quelles circonstances, le cas échéant?

Idéalement aucun

Mais ce n'est pas toujours possible. Je ne peux pas vous donner des chiffres précis comme 20% ou 10 lignes, c'est subjectif au point de ne pas pouvoir y répondre. Je peux décrire comment j'utilise les motifs de conception et les circonstances qui nécessitent de les plier légèrement.

Dans mon esprit, cela dépend entièrement de l'objectif de l'application. Construire une simple API REST à laquelle publier? Oubliez la séparation nette ou même un motif. Vous pouvez créer une version de travail en moins d'une heure. Construire quelque chose de plus grand? Le mieux serait probablement de travailler dessus.

L’objectif est de construire des systèmes contenus individuellement. Si vous commencez à écrire une logique métier spécifique à la manière dont deux systèmes interagissent, cela pose un problème. Sans approfondir, je ne peux pas donner d'opinion.

Les modèles de conception sont des moules, certains aiment s'y conformer strictement sur la base d'un code principal bien écrit. Adhérer strictement à un modèle ne vous donnera probablement pas un code incorrect , mais cela pourrait prendre plus de temps et vous faire écrire beaucoup plus de code.

Les modèles de conception sont flexibles, ajustez-les à vos besoins. Plie-les trop et ils cassent bien. Sachez ce dont vous avez besoin et choisissez un modèle de conception le plus proche.

Aussi petit que possible. De préférence aucun.

Le contrôleur doit s’occuper d’accepter la demande, de demander au bon service de domaine de traiter la demande et de transmettre la réponse à la vue correcte.

Dans ce processus, toute la "logique métier" doit exister dans les services de domaine.

Si vous avez une fonctionnalité qui prend les objets de domaine et crée des modèles de vue à partir d’eux, cela peut raisonnablement coexister avec le contrôleur. Mais cela devrait être un code qui n'existe que pour les vues correspondantes. S'il existe une règle de niveau commercial sur la désinfection des données, celle-ci doit exister dans votre domaine / niveau de service (avec les tests unitaires appropriés).

Le terme "logique métier" est souvent source de confusion car les gens ont des opinions divergentes sur ce que cela signifie. À mon avis, le terme "logique d'entreprise" recouvre deux domaines

• Logique de domaine
• Logique d'application

La logique de domaine est une logique liée au domaine principal de votre entreprise. Par conséquent, si vous écrivez une application pour des comptables, les règles fiscales, les règles de comptabilité, etc. font partie de la logique de domaine.

La logique d'application est une logique liée au fait que vous exécutez un programme informatique. Il peut s'agir par exemple d’importation, d’exportation, d’assistant d’exportation au format CSV, etc.

Le type de "logique métier" que vous pouvez placer dans la couche de contrôleur est la logique d'application. Peut-être que toute la logique d'application ne devrait pas y aller. Mais vous ne devez jamais placer la logique de domaine dans la couche contrôleur. Cela devrait évidemment être dans la couche de domaine.

Vous avez parlé de logique pour formater ou nettoyer les données. Le formatage doit absolument être une logique d'application. La désinfection, par contre, pourrait être une logique de domaine si la désinfection des données est basée sur des règles de domaine. Cela dépend du contexte.

Les contrôleurs doivent être très légers sur la logique de domaine.

Les contrôleurs doivent déléguer des tâches telles que récupérer un enregistrement du magasin de données au moyen d'une couche de service / référentiel abstraite et renvoyer des données dans le magasin de données par le même service (ou le service associé). En ce qui concerne la mécanique et le travail plus minutieux entre ces opérations, ils appartiennent généralement à un endroit autre que le contrôleur.

Je me trouve souvent en train d'ajouter de petites méthodes d'assainissement des données à mes contrôleurs, ce qui enregistre les données dans le magasin. Bien que cette solution soit efficace, elle ne cadre pas bien avec le rôle prévu du contrôleur. Idéalement, tout ce qui modifiera, validera ou analysera votre modèle devrait se situer très près du modèle lui-même. Par exemple, si vous devez "nettoyer" un objet de modèle avant de le stocker, envisagez d'utiliser une méthode SanitizeInputs () sur le modèle ou dans le cadre du service qui gère le stockage du modèle.

D'un point de vue pragmatique, j'ai constaté que la logique de votre contrôleur ou le comportement de votre contrôleur dans votre modèle vous empêchait de faire quelque chose pour lequel l'approche n'est pas conforme au modèle. Doublement, si vous écrivez une application qui ne dispose pas d'une grande infrastructure derrière elle.

Vous pouvez choisir l’un ou l’autre moyen, mais j’essaie généralement de penser si le bit étrange risque d’apparaître dans plus d’une action de contrôleur, s’il en est ainsi dans le modèle. Si cela n’est pas clair, j’essaie de me demander si c’est plus adapté à un endroit qu’à un autre. En cas d'échec, je le mets généralement dans le modèle pour le garder en dehors du contrôleur (préférence personnelle pour les contrôleurs plus petits et les objets de données plus puissants, YMMV)

Une troisième option consisterait à faire référence aux éléments d’utilité en tant que classe d’utilité distincte, mais c’est un peu à l’encontre du motif également.

En outre, juste parce que vous ne suivez pas strictement un modèle, vous ne flirtez pas nécessairement avec un désastre. Sauf si vous vous attendez vraiment à une quantité importante de code réutilisé par ce projet, je m'inquiéterais beaucoup plus de la cohérence du projet lui-même (c'est-à-dire: ne bascule pas sur l'endroit où vous mettez ces bits une fois que vous avez choisi un emplacement). qu’une réécriture qui, pour une raison quelconque, souhaite économiser une partie du milieu du projet. Documentez / commentez où et pourquoi vous vous êtes écartés du modèle commun et définissez le modèle attendu pour cette application.

MVC était un écart par rapport aux modèles établis à un moment donné.

À l'instar de nombreux autres concepts intéressants en programmation, MVC est un puissant paradigme qui permet de structurer et de cibler une famille de stratégies proches ou similaires pour mettre en œuvre certains scénarios.

Comme beaucoup d'autres concepts de programmation, MVC simplifie la réalité, élimine les petits détails et fournit un modèle filaire grossier à suivre. Comme beaucoup d’autres simplifications de la réalité, il s’agit d’apporter une structure au chaos, telle que la perçoit l’esprit humain.

Néanmoins, comme beaucoup d’autres concepts de programmation, MVS n’est qu’une simplification de la réalité. Ce n'est pas parfait et ce n'est pas approfondi. C'est pourquoi il n'est pas possible d'intégrer un scénario du monde réel dans un modèle trop simplifié. D'où de nombreuses questions similaires à celle-ci.

• Combien de logique devrait aller dans un contrôleur?

• Si une vue doit contenir une logique conditionnelle?

• Un modèle doit-il contenir des données supplémentaires non trouvées directement dans les entités commerciales?

Telles sont toutes des questions nées pour tenter d’adapter le code à l’idée conceptuelle de MVC de manière précise et complète.

Ma réponse à vous est de ne pas essayer. MVC fournit la structure. Construisez votre application autour de cette base, mais ne vous attendez pas à ce qu'elle soit parfaitement adaptée. Il y aura des déviations, c'est normal. Il suffit de regarder pour les garder sous contrôle.