MVC: modèles de données et modèles de vue

Question

J'ai lu quelques MVC conseils dans le passé concernant les modèles indiquant que vous ne devez pas réutiliser le même modèle les objets du domaine et de la vue; mais je n'ai pas été en mesure de trouver quelqu'un disposé à discuter de pourquoi c'est mauvais.

Il est de mon avis que la création de deux modèles distincts - un pour le domaine, l'un pour la vue - et puis mappage entre eux crée beaucoup de duplication, plus fastidieux de mappage de code (dont certains pourraient être atténuées par des choses comme AutoMapper) qui seront probablement enclins à faire des erreurs.

Ce qui fait qu'un modèle distinct pour les deux préoccupations de la peine de la duplication et de la cartographie de code?

Answer 1

En son cœur, les deux modèles est de la Séparation des Préoccupations. Je veux mon point de Vue à travailler avec un Modèle unique. Je veux que mon Modèle de Domaine pour représenter le modèle conceptuel-je construire avec les experts du domaine. ViewModel a souvent des contraintes techniques. Modèle de domaine est d'environ POCO, et n'étant pas lié par les contraintes techniques de données (point de Vue) ou persistantes (en DB ou autre).

Supposons que j'ai trois entités affichées sur un écran. Est-ce à dire j'ai besoin de la force d'une relation entre les trois? Ou tout simplement créer un ViewModel composant de l'objet qui contient les trois éléments. Avec un ViewModel, Vue préoccupations sont séparés de mon domaine.

Answer 2

Pourquoi? Parce que la vue ne devrait pas avoir la capacité d'utiliser l'objet de modèle!

Imaginez que vous transmettiez le projet à un concepteur Web pour créer la couche de vue. Soudain, il / elle a la possibilité de manipuler les données de votre application via la couche de modèle. Ce n'est pas bon.

Donc, ne passez toujours que les données dont la vue a besoin, au lieu de l'objet avec les méthodes.

Answer 3

J. P. Boodhoo l'article d' Écran Lié Otd vous aidera à comprendre l'avantage de conception.

Il y a aussi une prestation de sécurité que j'ai écrit au sujet de.

Avoir un modèle de présentation simplifie votre point de vue. Ceci est particulièrement important parce que les vues sont généralement très difficiles à tester. En ayant un modèle de présentation vous déplacez beaucoup de travail hors de la vue et dans le domaine->modèle de présentation. Des choses comme la mise en forme, la manipulation des valeurs null et l'aplatissement de graphes d'objets.

Je suis d'accord que le supplément de la cartographie est une douleur, mais je pense que vous avez probablement besoin d'essayer les deux approches dans votre contexte particulier de voir ce qui fonctionne le mieux pour vous.

Answer 4

Il existe des préoccupations encore plus évidentes, notamment la capacité du modèle de vue à être spécialement formaté et certainement null-safe.

Answer 5

J'imagine que l'idée est que vos modèles de domaine pourraient s'étendre à d'autres implémentations, pas seulement à votre application MVC, ce qui violerait le principe de séparation des préoccupations. Si votre modèle de vue EST votre modèle de domaine, votre modèle de domaine a deux raisons de changer: une exigence de changement de domaine ET une modification de l'exigence de vue.