Que mettre dans votre ViewModel

Question

Et que mettez-vous dans votre View?

Un blog récent de Scott Hanselman sur l'utilisation d'un liant spécial modèle pour le test plus facile m'a amené à penser à ce qui suit: Qu'est-ce que vous mettez dans votre logique de commande la construction du modèle de vue, et ce qui doit être mis dans la vue? ce qu'il fait est le suivant:

var viewModel = new DinnerFormViewModel { 
    Dinner = dinner, 
    Countries = new SelectList(PhoneValidator.Countries, dinner.Country) 
}; 
return View(viewModel); 

Maintenant, j'utilise la même manière de transmettre des données à mon avis, mais je ne suis pas sûr de la façon dont il traite la propriété des pays. Vous pouvez argumenter des deux côtés: Envelopper la liste des pays dans la liste SelectList prépare les données pour la vue, tout comme vous créez un DTO viewmodel pour transmettre vos données. D'autre part, il semble que vous manipulez spécifiquement les données à utiliser dans une liste déroulante, ce qui limite la façon dont la vue traite vos données depuis le contrôleur. Je pense que c'est un peu une zone grise sur la séparation des soucis entre la vue et le contrôleur, et je ne peux pas vraiment décider quel chemin à parcourir. Existe-t-il des meilleures pratiques pour cela? PS: Pour rester simple, supposons le contexte ASP.NET MVC par défaut, donc, fondamentalement, votre projet initial. Moteur de vue par défaut et tout ce jazz.

Answer 1

Dans MVC (au moins cette saveur), une des responsabilités du contrôleur est de préparer les données pour la vue. Je pense donc qu'il est parfaitement acceptable de préparer un modèle spécifique pour la consommation des vues qui implique qu'il sera utilisé dans une liste déroulante. Dans ce cas, le contrôleur facilite simplement la vue et empêche en fait que le code gênant ne soit autrement transmis à la vue. Il empêche également d'avoir ces chaînes magiques dans le ViewData comme VieData ["Pays"]. Pour résumer, même s'il peut sembler qu'il y ait une zone grise en termes de responsabilités, en fin de compte c'est le travail du contrôleur: interagir avec la vue et transformer le modèle de domaine en d'autres modèles qui sont plus faciles consommer par la vue.

Answer 2

Certains suggèrent que l'idéal est d'avoir un seul modèle de vue englobant par vue (nommé Thunderdome Principle).