Quelle quantité de logique métier devrait être autorisée à exister dans la couche contrôleur?
Parfois, nous avons une logique métier représentée dans le code contrôleur de nos applications. Il s'agit généralement d'une logique qui différencie les méthodes à appeler à partir du modèle et/ou les arguments pour les passer.
Un autre exemple de cela est un ensemble de fonctions utilitaires qui existent dans le contrôleur et qui peuvent fonctionner pour formater ou nettoyer les données renvoyées par le modèle, selon un ensemble de règles métier.
Cela fonctionne, mais je me demande si son flirt avec le désastre. S'il y a 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éroutée par cette inégalité dans l'emplacement du code lié à la logique métier.
Ma question est de savoir quelle quantité de logique métier doit ê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 de chiffres durs comme 20% ou 10 lignes, c'est subjectif au point où il ne peut pas être répondu. Je peux décrire comment j'utilise les modèles de conception et les circonstances qui nécessitent de les plier légèrement.
À mon avis, tout dépend de l'objectif de la demande. Construire une simple REST api à publier sur? Oubliez une séparation nette ou même un modèle. Vous pouvez produire une version de travail en moins d'une heure. Construire quelque chose de plus grand? Il vaut probablement mieux y travailler.
La construction de systèmes contenus individuellement est l'objectif. Si vous commencez à écrire une logique métier spécifique à la façon dont deux systèmes interagissent, c'est un problème. Sans aller plus loin, je ne peux pas donner d'avis.
Les modèles de conception sont des moules, certains aiment s'y conformer strictement sur la base d'un code principal et bien écrit. Adhérer strictement à un modèle ne vous donnera probablement pas un mauvais code , mais cela pourrait prendre plus de temps et vous faire écrire beaucoup plus de code .
Les modèles de conception sont flexibles, ajustez-les en fonction de vos besoins. Pliez-les trop et ils se cassent cependant. Sachez ce dont vous avez besoin et choisissez un modèle de conception le plus proche de cela.
Aussi petit que possible. De préférence aucun.
Le contrôleur doit être soucieux d'accepter la demande, de demander au service de domaine correct 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 disposez d'une fonctionnalité qui prend des objets de domaine et en crée des modèles d'affichage, cela peut raisonnablement coexister avec le contrôleur. Mais cela devrait être du code qui existe seulement pour les vues correspondantes. S'il existe une règle au niveau de l'entreprise concernant le nettoyage 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 déroutant car les gens ont des opinions différentes sur ce que cela signifie. À mon avis, le terme "logique métier" couvre deux domaines
- Logique de domaine
- Logique d'application
La logique de domaine est une logique liée au domaine principal auquel votre entreprise se rapporte.Par conséquent, si vous rédigez une candidature pour les comptables, les règles fiscales, les règles de tenue de livres, etc. font partie de la logique du domaine.
La logique d'application est une logique liée au fait que vous exécutez un programme informatique. Il peut s'agir de choses telles que l'exportation d'import CSV, des assistants, etc. Peut également contenir des choses comme la création d'e-mails de mot de passe oubliés.
Le type de "logique métier" que vous pouvez placer dans la couche 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 de logique de domaine dans la couche contrôleur. Cela devrait évidemment être dans la couche domaine.
Vous parliez de logique pour formater ou aseptiser les données. Le formatage doit définitivement être une logique d'application. La désinfection, d'autre part, 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 du domaine.
Les contrôleurs doivent déléguer des tâches telles que la récupération d'un enregistrement du magasin de données au moyen d'une couche de service/référentiel abstraite et la retransmission des données dans le magasin de données par le même service (ou un service associé). Quant à la mécanique et au travail plus fin entre ces opérations, elles appartiennent généralement à un autre endroit que le contrôleur.
Je me retrouve souvent à ajouter de petites méthodes d'assainissement des données à mes contrôleurs qui sauvegardent les données dans le magasin et bien que ce soit une solution efficace, elle ne correspond pas bien au rôle prévu du contrôleur. Idéalement, tout ce qui modifiera, validera ou analysera votre modèle devrait se produire très près, sinon à l'intérieur, du modèle lui-même. Par exemple, si vous devez "nettoyer" un objet modèle avant de le stocker, envisagez d'avoir 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 vous vous retrouvez avec une logique dans votre contrôleur ou un comportement de contrôleur dans votre modèle lorsque vous essayez de faire quelque chose pour lequel il n'y a pas une bonne approche conforme aux modèles. Doublement donc si vous écrivez une application qui n'a pas de grande infrastructure derrière elle.
Vous pouvez aller dans les deux sens, mais j'essaie généralement de penser si le bit étrange est susceptible d'apparaître dans plus d'une action de contrôleur, si c'est le cas dans le modèle. Si cela n'est pas clair, j'essaie de penser s'il est plus "approprié" à un endroit qu'à l'autre. À défaut, je le mets généralement dans le modèle juste pour le garder hors du contrôleur (préférence personnelle pour les petits contrôleurs et les objets de données plus forts, YMMV)
Une troisième option consisterait à référencer les éléments d'utilité en tant que classe d'utilité distincte, mais cela est quelque peu contraire au modèle, de l'avis de beaucoup.
De plus, juste parce que vous ne suivez pas strictement un modèle, vous ne flirtez pas nécessairement avec une catastrophe. À moins que vous ne vous attendiez vraiment à une réutilisation importante de code hors de ce projet, je m'inquiéterais beaucoup plus du fait que le projet soit cohérent avec lui-même (c'est-à-dire: ne vous retournez pas sur l'endroit où vous placez ces bits une fois que vous avez choisi un emplacement) qu'une réécriture qui, pour une raison quelconque, veut sauver une partie du milieu du projet. Documentez/commentez où et pourquoi vous vous êtes écarté du modèle commun et définissez le modèle attendu pour cette application.
MVC était une déviation des modèles établis lui-même à un moment donné.
Comme de nombreux autres concepts intéressants en programmation, MVC est un paradigme puissant pour structurer et concentrer une famille de stratégies proches ou similaires pour implémenter certains scénarios.
Comme de nombreux autres concepts de programmation, MVC simplifie la réalité, ignore les petits détails et fournit un modèle filaire brut à suivre. Comme de nombreuses autres simplifications de la réalité, cela ne fait que mettre la structure dans le chaos vu par un esprit humain.
Pourtant, 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 complet. 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.
Quelle quantité de logique doit entrer dans un contrôleur?
Si une vue doit contenir une logique conditionnelle?
Si un modèle doit contenir des données supplémentaires qui ne se trouvent pas directement dans les entités commerciales?
Ce sont toutes des questions nées dans une tentative d'ajuster le code pour l'adapter précisément et complètement à l'idée conceptuelle de MVC.
Ma réponse est de ne pas essayer. MVC fournit une structure. Construisez votre application autour de cette fondation, mais ne vous attendez pas à ce qu'elle s'adapte parfaitement. Il y aura des écarts, c'est normal. Regardez juste pour les garder sous contrôle.