Thunderdome MVC- Pourquoi un modèle unique en MVC?

Question

Lorsque Jeremy & Tchad posted about their FubuMvc project, l'un des différenciateurs ils ont mentionné était leur « Thunderdome principal »:

Le « Thunderdome Principe » - Tous les méthodes contrôleur prennent dans un objet ViewModel (ou zéro objets certains cas) et retourner un seul objet ViewModel (un objet entre, un objet quitte). Les classes Controller ne seront JAMAIS directement exposées à tout ce qui est lié à HttpContext. Rien ne me fait pleurer comme voir les gens qui essaient d'écrire des tests qui se moquent ou stub cette nouvelle interface IHttpContextWrapper . De même, les méthodes du contrôleur ne renvoient pas d'objets ViewResult et sont généralement découplées de de toute l'infrastructure MVC. Nous adopté cette stratégie très tôt comme une façon de rendre le contrôleur de test plus simple mécaniquement. C'est certainement atteint cet objectif, mais il est également fait le code du contrôleur très simplifié et facile à lire. Nous allons expliquer comment cela fonctionne à KaizenConf.

Quel est l'avantage de leur 'un ViewModel (ou zéro) dans' approche?

Answer 1

Son principal avantage est que c'est une convention et rend les choses cohérentes dans tous nos contrôleurs. Il nous est plus facile de configurer des «contextes»/appareils de test capables d'initialiser l'environnement dans un scénario de test d'intégration. Dans la plupart des cas, Conventions == Rapidité car il supprime beaucoup de scénarios «et si» de vos considérations de conception.

Puisque toutes nos actions de contrôleurs suivent le même modèle, nous pouvons supposer beaucoup de choses et cela accélère et rationalise nos efforts de test intégrés de contrôleur. Il n'y a rien de mal, nécessairement, à avoir plusieurs arguments pour une action de contrôleur, mais nous avons trouvé que l'existence d'un objet modèle nous offre des fonctionnalités supplémentaires car le modèle peut contenir une logique simple et exposer des propriétés de commodité qui peuvent simplement aspects plus complexes de son propre état, etc - en gros, c'est l'argument pour avoir n'importe quel modèle riche et n'est pas unique au modèle Thunderdome/OMIOMO.

Answer 2

L'avantage est que vous ne comptez pas sur un type de contexte (comme un état de session, par exemple) de l'extérieur des méthodes du contrôleur. Cela rend plus facile de les tester, car vous n'avez pas à "simuler" ce contexte en utilisant des simulacres, mais cela le rend également moins pratique car vous devez tout passer par des paramètres.

Answer 3

L'avantage du principe du tonnerre est qu'il simplifie les contrôleurs. Comme le mappage des valeurs http aux objets se fait en dehors des contrôleurs, cela signifie que les contrôleurs ne font que ce qu'ils doivent faire.