MVC Utilisation de modèles de domaine dans les modèles de vue

Personnellement, j’utilise des modèles de domaine dans la vue s’ils correspondent naturellement parfaitement . Cela ne se produira probablement que sur des projets sortingviaux de nature CRUD (éditer les entités de domaine de manière simple). Je trouve une perte de temps de créer une copie exacte d’une entité de domaine pour des raisons de pureté.

Je ne modifierai jamais un modèle de domaine pour rendre compte des besoins de la vue. Dans plus de 95% de mes projets, c’est la situation dans laquelle je me trouve. Dès que vous polluez le domaine pour le plaisir de la vue, vous introduisez des problèmes de maintenabilité.

Cela dépend de ce que vous entendez par “modèle de domaine”. Voulez-vous dire des entités EF? Ou parlez-vous des objects de la couche de gestion?

Ce n’est jamais une bonne idée de passer des entités EF à la vue, en particulier si vous utilisez la liaison de modèle par défaut. Cela peut créer des problèmes de sécurité si vous ne faites pas attention. Bien que les mêmes problèmes puissent se produire si vous ne faites pas attention aux objects métier transmis à la vue.

L’un des principaux avantages des modèles de vue est que vous disposez d’un contrôle beaucoup plus précis sur la cartographie des données. Vous pouvez ainsi valider plus facilement que seules les cartes correctes sont générées.

Tout se résume cependant à votre application. Si c’est une application simple, il ne vaut peut-être pas la peine de faire des mappages plus complexes. S’il s’agit d’une application complexe, qui doit vivre longtemps et susceptible de faire l’object de nombreuses mises à jour, vous devez absolument investir vos efforts.

J’ai longtemps lutté contre la duplication perçue provoquée par des modèles de vue distincts et des modèles de domaine. J’affirmerais que, puisqu’elles sont destinées à des fins différentes, il ne s’agit pas vraiment d’une duplication, mais il est toujours “erroné” de déclarer autant de propriétés similaires.

Dans les très petits projets (en particulier ceux avec un groupe d’utilisateurs authentifiés hautement fiable), je peux simplement me lier directement aux modèles de domaine et en finir avec. Ou bien je peux mélanger et assortir si le modèle de vue nécessite une structure différente (comme décrit par E. Eric J.).

Cependant : ModelBinder tentera de faire correspondre les valeurs de la requête aux propriétés de votre modèle. Cela signifie que toute propriété de votre modèle de domaine peut potentiellement être renseignée par une demande (non autorisée). Il existe des moyens d’éviter cela, mais pour moi, la tranquillité d’esprit l’emporte sur un petit effort supplémentaire pour créer des modèles de vue distincts.

Je ne vois pas le besoin absolu de créer un modèle de vue distinct pour les valeurs non liées en lecture seule (éventuellement la liste des types d’utilisateurs dans votre cas, bien que public virtual ICollection Logins puisse annuler cette opération).

Vous pouvez également projeter le modèle de domaine sur une abstraction orientée interface utilisateur (par exemple, IEnumerable ). Vous pouvez utiliser SelectListItems pour une variété de mécanismes de saisie afin de ne pas vous attacher à un comportement d’interface utilisateur particulier.

Même avec une abstraction, vous devrez peut-être toujours vérifier que la demande ne contient pas de valeur non autorisée. Par exemple, seuls les super-administrateurs peuvent atsortingbuer certains ID UserTypeDomainModel . Indépendamment de l’abstraction, vous devez toujours valider ceci.

TLDR: modélisez autant que possible les modèles de domaines abstraits, trouvez les abstractions appropriées (un nouveau modèle de vue ne correspond pas toujours à la bonne réponse) et soyez (légèrement paranoïaque) à propos de la validation des entrées.