3

J'ai une question sur asp.net mvc-2 vues partielles fortement typées, et voir les modèles. Je me demandais juste si je pouvais (ou devais) avoir deux vues partielles fortement typées sur une page, sans implémenter un tout nouveau modèle de vue pour cette page. Par exemple, j'ai une page qui affiche des profils, mais a également un formulaire en ligne pour ajouter un contact rapide. Chacune de ces entités possède déjà son propre modèle de vue, c'est-à-dire que j'ai un ProfileViewModel et un ContactViewModel. Donc, ma vue a besoin de deux vues partielles fortement typées, l'une utilisant une liste IEnumerable de ProfileViewModels, et l'autre utilisant un ContactViewModel. Est-il possible ou souhaitable d'éviter de créer un troisième modèle de vue, un 'IndexViewModel' pour cette page, qui contient une liste de ProfileViewModels et un ContactViewModel? Est-ce que la mise en œuvre de ce modèle de vue n'est pas une mauvaise pratique, ou est-ce parce que cela entraîne moins de modèles de vue?Les vues partielles fortement typées sur une page dans asp.net mvc-2 doivent-elles avoir un modèle de vue combiné?

Merci!

Répondre

1

Si les deux vues partielles requièrent des modèles de vue déjà définis, la page qui héberge ces partiels doit fournir les modèles de vue d'une manière ou d'une autre. Il est facile d'imaginer comment un IEnumerable<ProfileViewModel> doit être fourni à la page contenant, car les informations de contact arrivent probablement de l'arrière. Le ContactViewModel contient-il des données? Si ce n'est pas le cas, vous pourriez être capable de le créer sur place dans la vue de la page contenant, et de vous en passer en lui passant seulement un IEnumerable<ProfileViewModel>. Sinon, la vue contenant doit recevoir à la fois un IEnumerable<ProfileViewModel> et un ContactViewModel. L'option sur laquelle je me pencherais est en effet la définition d'un nouveau modèle de vue qui a des membres de données pour ces deux valeurs. Il est un peu mieux documenté et permet une meilleure vérification du type de compilateur que l'alternative de passer ces valeurs via ViewData[].

Un peu implicite dans votre question est l'idée que la création d'un modèle de vue est une corvée. Cela pourrait bien être le cas pour les vues partielles, si la définition du modèle de vue reflète simplement celle d'une entité dorsale. Si tel est le cas, vous pouvez envisager de passer directement l'entité principale au lieu de dupliquer sa définition et son contenu dans un modèle de vue.

Enfin, les vues-modèles ne sont qu'un outil. Utilisez-les s'ils ajoutent de la valeur. Certaines applications gagnent en clarté, en documentation et en avantages de couplage en utilisant des classes distinctes de modèles de vues. D'autres, souvent des applications plus petites, ne gagnent pas assez pour mériter l'overhead. Il n'y a rien de «mauvaise pratique» inhérent à ne pas implémenter des modèles de vue (ou n'importe quel autre modèle de conception, d'ailleurs). C'est un choix de conception dont vous pouvez vous sentir à l'aise si vous avez un argument raisonnable en sa faveur.

+0

Merci. Il semble que la création d'un autre modèle de vue serait un peu plus ordonnée et plus facile à tester? D'autant qu'il n'est pas difficile d'en faire un. Parfois, il est difficile de voir ce qui est une bonne pratique et ce qui est simplement un choix de conception, et cela m'a beaucoup aidé. – Kai

+0

Comment suis-je la première personne à donner +1? Bonne réponse, merci! –

Questions connexes