MVC, où générer des classes ViewModel?

Question

où la création de ViewModel doit-elle avoir lieu? Dans la couche de service, dans le contrôleur?

public class ObjectA { 
public string Name {get;set;} 
public IList<ChildB> Children {get;set;} 
} 

public class ObjectAViewModel { 
public ObjectA ObjectA {get;set;} 
public IList<ChildB> SelectableChildren {get;set;} 
} 

si certaines propriétés sur ObjectA doivent être calculés lors de l'exécution?

public class ObjectA { 
public string Name {get;set;} 
public IList<ChildB> Children {get;set;} 
public CalculateMethod {get;set;} 
public decimal CalculatedValue {get;set;} 
} 

permet de dire que ObjectA.CalculatedValue est calculé sur tout ou partie des objets ChildB dans le référentiel (non seulement les objets liés), et qu'ils sont calculés différemment en fonction de la valeur CalculateMethod? Devrais-je étendre le ObjectA, et dans ce cas, où devrais-je le mettre? avec ObjectA ou, en tant que DTO ailleurs? Et où le calcul devrait-il avoir lieu?

Answer 1

Cela semble être une question non triviale. Il y a un point de départ pour la réflexion here et à partir de là des références à d'autres discussions.

Je suis d'un milieu Java et donc ne pas l'expérience directe de votre monde, mais à un niveau conceptuel ma pensée va:

Les modèles ne savent pas quoi que ce soit sur les vues, ils ont juste rendre les données disponibles et peut également mettre à disposition des règles de validation que les vues peuvent trouver utiles. Par exemple: voici une date, ce champ est le champ "Département". Voici une liste de tous les départements valides, en tant que modèle, je ne sais rien à propos de Mr View mais je suppose que vous pourriez remplir une liste déroulante de cette liste de départements.

Le problème qui est que le modèle peut finir par envoyer d'énormes quantités de données que la vue ne se soucie pas, lisez la suite ...

Les contrôleurs ne savent rien sur le contenu réel de vues et les modèles, mais ils savent que certains points de vue s'intéressent à certains modèles. Ils ont donc la responsabilité de sélectionner un point de vue et de l'organiser pour obtenir les données dont il a besoin. Le contrôleur est plutôt comme une agence de rencontres, faire des présentations, mais ensuite s'éloigner.

Ainsi, dans le scénario le plus général, View lui-même reçoit un modèle et s'aide des données dont il a besoin. Donc, la vue connaît le modèle, mais pas l'inverse. Maintenant, en tant que détail d'implémentation, nous pouvons sortir de cette relation une classe ViewModel, pour contenir les données intéressantes pour la vue et nous pouvons également extraire la logique vers une classe ViewModelFactory. Le contrôleur peut en fait avoir la responsabilité de sélectionner le ViewModelFactory approprié sur la base de la vue à laquelle nous allons, et par conséquent le contrôleur est en train de "fabriquer" le ViewModel, mais la logique est la responsabilité de la vue (conceptuelle).

Answer 2

Pour votre première question, je dirais dans le contrôleur car c'est lui qui sait quelle vue il servira, donc ce que cette vue a besoin de savoir.