ASP.NET MVC, Model et ViewModel séparation des problèmes?

Question

Dernièrement, j'ai exploré le meilleur moyen d'organiser la couche de présentation d'une application ASP.NET MVC lorsque le modèle sous-jacent est complexe. Ce qui est arrivé jusqu’à présent, c’est l’architecture MVVM avec ses objets ViewModel. Cependant, je ne sais pas quelles sont les meilleures pratiques lorsque ce type d’architecture est envisageable.

• Les objets ViewModel peuvent-ils contenir des objets Modèle?
• Si MVVM est utilisé, est-il conseillé d'utiliser les objets Modèle dans les vues?
• Où la validation devrait-elle être mise en œuvre, sur les classes ViewModel ou Model?
• La couche de gestion (couche de service) doit-elle connaître ViewModel et qui est responsable du mappage entre ViewModel et Model?

Answer 1

• La plupart du temps, les objets ModelView ne sont que des conteneurs contenant des objets Model lorsque nous devons en envoyer plusieurs types ou lorsque nous devons transmettre quelques propriétés supplémentaires qui ne sont nécessaires que dans les vues.
• Si le travail de View consiste à afficher les détails d'un modèle et qu'il n'y a rien d'autre à transférer à View, pourquoi pas?
• Cela dépend. Vous pouvez utiliser vos classes ModelView et Model uniquement pour transporter des données entre des couches. Et prenez en charge la validation via des classeurs de modèle Cutom ou avec une couche de service.
• Il n'y a aucune raison pour qu'ils ne connaissent pas ModelViews. Mais en général, vous obtenez simplement le ou les modèles demandés à partir de la couche service du contrôleur, puis vous les transmettez directement ou dans une vue ModelView à la vue.

BTW, je ne considérerais pas ModelViews comme une architecture. Cela ressemble plus à "utilisez-en un quand vous en avez besoin". Après tout, cela ne sert à rien de transmettre des données à afficher:

class SomeModelView {
    public MyModel model { get; set; }
}

Passez simplement le MyModel si cela suffit pour que la vue fasse son travail.