Des mannequins gros et des contrôleurs maigres, c'est un peu comme si on créait des modèles de Dieu.

Question

J'ai lu beaucoup de blogs qui prônent la des mannequins obèses et des contrôleurs maigres notamment le camp Rails. En conséquence, les routeurs ne font que déterminer quelle méthode appeler sur quel contrôleur et tout ce que la méthode du contrôleur fait est d'appeler la méthode correspondante sur le modèle et ensuite d'afficher la vue. J'ai donc deux préoccupations que je ne comprends pas :

1. Le contrôleur et le routeur n'effectuent pas vraiment de tâches différentes, si ce n'est qu'ils appellent une méthode sur le modèle de type Dieu en fonction de la route.
2. Les modèles en font trop. Envoi d'e-mails, création de relations, suppression et modification d'autres modèles, mise en file d'attente de tâches, etc. En fait, vous avez maintenant des objets semblables à des dieux qui sont censés faire tout ce qui peut ou non concerner la modélisation et le traitement des données.

Où se situe la limite ? Ne s'agit-il pas simplement d'un modèle de Dieu ?

Answer 1

_{Ce n'est peut-être pas la meilleure idée de considérer Rails comme un modèle de conception MVC. Ce framework a été conçu avec des défauts inhérents (je l'ai un peu développé dans un article de <a href="https://stackoverflow.com/a/11984678/727208">autre poste </a>) et la communauté commence à peine à s'attaquer aux conséquences. Vous pouvez consulter DataMapper2 <a href="http://www.youtube.com/watch?v=MU4RvuvpT8w" rel="noreferrer">développement </a>comme première étape importante.}

Un peu de théorie

Les personnes qui donnent ce conseil semblent être affligées d'une idée fausse assez répandue. Permettez-moi donc de commencer par la dissiper : Le modèle, dans le modèle de conception MVC moderne, n'est PAS une classe ou un objet. Le modèle est une couche.

L'idée de base du modèle MVC est la suivante Séparation des préoccupations et la première étape est la division entre la couche de présentation et les couches de modèle. Tout comme la couche de présentation se décompose en contrôleurs (instances, responsables de la gestion des entrées utilisateur), vues (instances, responsables de la logique de l'interface utilisateur) et modèles/présentations, il en va de même pour la couche de modèle.

Les principales parties de la couche modèle sont les suivantes :

• Objets du domaine

  Également connus sous le nom d'entités de domaine, d'objets d'entreprise ou d'objets de modèle (je n'aime pas ce dernier nom car il ne fait qu'ajouter à la confusion). Ces structures sont ce que les gens appellent généralement à tort des "modèles". Elles sont chargées de contenir les règles de gestion (tous les calculs et la validation d'une unité spécifique de la logique du domaine).

• Abstractions de stockage :

  Généralement mis en œuvre à l'aide de données mappeur (à ne pas confondre avec ORMs qui ont abusé de ce nom). Ces instances sont généralement chargées de stocker des informations - à partir des objets du domaine et de les récupérer - dans les objets du domaine. Chaque objet de domaine peut avoir plusieurs mappers, tout comme il existe plusieurs formes de stockage (DB, cache, session, cookies, /dev/null).

• Services :

  Structures responsables de la logique d'application (c'est-à-dire l'interaction entre les objets du domaine et l'interaction entre les objets du domaine et les abstractions de stockage). Elles doivent agir comme l'"interface" par laquelle la couche de présentation interagit avec la couche de modèle. C'est généralement ce qui, dans un code de type Rails, se retrouve dans les contrôleurs.

Il existe également plusieurs structures qui pourraient se trouver dans les espaces entre ces groupes : OAA , unités de travail y dépôts .

_{Oh ... et lorsque nous parlons (dans le contexte du web) d'une <em>utilisateur </em>qui interagit avec l'application MVC, ce n'est pas un être humain. L'"utilisateur" est en fait votre navigateur web.}

Qu'en est-il des divinités ?

Au lieu de travailler avec un modèle effrayant et monolithique, les contrôleurs devraient interagir avec des services. Vous transmettez des données provenant de l'entrée de l'utilisateur à un service spécifique (par exemple MailService o RecognitionService ). De cette manière, le contrôleur modifie l'état de la couche de modèle, mais en utilisant une API claire et sans toucher aux structures internes (ce qui entraînerait une fuite de l'abstraction).

Ces changements peuvent soit provoquer une réaction immédiate, soit n'affecter que les données que l'instance de vue demande à la couche de modèle, soit les deux.

Chaque service peut interagir avec n'importe quel nombre (bien qu'il ne s'agisse généralement que d'une poignée) d'objets de domaine et d'abstractions de stockage. Par exemple, l'abstraction RecogitionService se moque éperdument des résumés de stockage des articles.

Notes de clôture

On obtient ainsi une application qui peut être testée à l'unité à tous les niveaux, dont le couplage est faible (si elle est correctement mise en œuvre) et dont l'architecture est clairement compréhensible.

Cependant, il faut garder à l'esprit que MVC n'est pas conçu pour les petites applications. Si vous écrivez une page de livre d'or en utilisant le modèle MVC, vous faites fausse route. Ce modèle est destiné à mettre en œuvre la loi et l'ordre sur des applications à grande échelle.

_{Pour les personnes qui utilisent PHP comme langue principale, <a href="https://stackoverflow.com/a/5864000/727208">ce poste </a>pourrait être pertinent. Il s'agit d'une description un peu plus longue de la couche modèle avec quelques extraits de code.}

Answer 2

Si les classes "modèles" sont mal implémentées, oui, votre préoccupation est pertinente. Une classe modèle ne devrait pas faire de l'Email (tâches d'infrastructure).

La vraie question est de savoir ce qu'implique le modèle dans MVC. Il n'est pas limité aux classes POCO avec quelques méthodes. Le modèle dans MVC signifie les données et la logique d'entreprise. Traitez-le comme un super-ensemble de modèles POCO classiques.

Vue ==== Contrôleur ==== Modèle ---> Couche processus métier --> Modèles de base

Ajoutez des assemblages d'infrastructure et des couches d'accès aux données et utilisez l'injection pour les intégrer à la BPL, et votre processus utilise MVC comme prévu.

La BPL peut invoquer des modèles d'utilité/de référentiel, exécuter des règles commerciales et appeler des fonctions d'infrastructure par le biais d'objets injectés ou de modèles d'interface.

Ainsi, la recommandation de garder un contrôleur maigre ne signifie pas que la classe "personne" dans un modèle Core classique devrait avoir 50 méthodes et appeler directement l'email. Vous avez raison de penser que c'est une erreur.

Le contrôleur peut toujours être tenu d'instancier et d'injecter des classes d'infrastructure dans la couche BPL ou la couche centrale s'il est appelé directement. Il devrait y avoir une couche métier ou au moins des classes orchestrant les appels à travers les classes du modèle objet classique. C'est en tout cas mon point de vue ;-)

Pour un point de vue générique sur MVC, la description du wiki http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Un petit blog qui parle du "M" de MVC. http://www.thedeveloperday.com/skinny-controllers/

Answer 3

Je pense qu'il est possible de faire une distinction entre un modèle unique (éventuellement nommé App ou Application) et plusieurs modèles décomposés en groupes logiques (Business, Customer, Order, Message). C'est dans ce dernier cas que je structure mes applications, et chaque modèle correspond à peu près à une table dans une base de données relationnelle ou à une collection dans une base de données documentaire. Ces modèles gèrent tous les aspects de la création, de la mise à jour et de la manipulation des données qui composent le modèle, qu'il s'agisse de communiquer avec la base de données ou d'appeler une API. Le contrôleur n'est responsable que de l'appel du modèle approprié et de la sélection d'un modèle.