En supposant que vous vouliez développer vos contrôleurs afin que vous utilisiez une vue de vue pour contenir des données pour les vues que vous rendez, devriez-vous toutes les données être contenues dans la viewModel? Quelles conditions seraient-elles acceptables de contourner la viewModel?
La raison pour laquelle je demande est que je suis dans une position où certains du code utilisent ViewData et certains utilisent le point de vue de la vue. Je tiens à distribuer un ensemble de directives dans l'équipe lorsqu'il est juste d'utiliser la viewdata, et quand il suffit de prendre des raccourcis. J'aimerais des opinions d'autres développeurs qui ont traité cela afin que je sache que mes directives ne soient pas seulement biaisées.
4 Réponses :
Je n'utilise personnellement jamais ViewData, tout passe par le modèle, sauf lorsque je teste quelque chose et j'ai rapidement besoin de pouvoir voir la valeur à la vue. Fortedyping!
Je suis complètement d'accord. Les cordes magiques sont au mieux laid et au pire des problèmes. Cela dit, j'utilise également la vueData pour tester rapidement des trucs, mais le problème est quand cela finit comme la solution permanente!
Oui - 100% d'accord. Je préférerais si cela pourrait même être obsolète.
@ Pure.krome: Vous pouvez certainement imiter l'amortissement en utilisant la méthode décrite dans mon poste. Remplacez la propriété ViewData dans un contrôleur de base et l'ajout de l'attribut [obsolète ()] vous donnerait le même résultat (essentiellement).
juste pour davantage le commentaire de Fabian; Vous pouvez explicitement garantissemment que les visionnements ne sont jamais utilisés en suivant les étapes décrites dans cet article . Il n'y a vraiment aucune excuse pas pour utiliser des modèles pour tout.
Si vous n'avez pas d'autre choix que d'utiliser ViewData (disons sur un projet existant); Au moins, utilisez les constantes de cordes pour résoudre les noms pour éviter d'utiliser des «chaînes magiques». Quelque chose dans les lignes de: ViewData [ViewDatakeys.Mykey] = Myvalue; Enfut, j'en utilise pour seulement tout ce qui doit être "basé sur des chaînes" (clés de session, clés de cache, cache de sortie VarybyCustom clés, etc.).
+1 - Nous utilisons toujours des images de vue fortement typées ici, mais utilisons viewdata pour de petits morceaux de "garniture" supplémentaires. Cela ne se produit généralement que pour nous dans des vues partielles réutilisées dans une variété de lieux.
@JIM: D'accord, il existe des scénarios (comme des vues partielles partagées) où cela est inévitable; Donc, mieux pour prendre des mesures pour empêcher de vous tirer dans le pied lorsque vous devez revenir en utilisant ViewData :)
Qu'entendez-vous des constantes à cordes VS Magic Strings, et pourquoi utilise-t-elle les visionneuses dans des vues partielles partagées inévitables?
@Howiecamp: une constante de chaîne est au moins fortement typé ; Ils devraient donc toujours être préférés à utiliser un littéral à chaîne pour accéder aux données de dictionnaire (cela vous donne également un bon «registre» des clés dans un endroit fixe également). En ce qui concerne l'utilisation de ViewData étant «inévitable», ce n'est pas complètement précis - mais il est parfois la meilleure alternative à essayer de créer une sorte de modèle «dieu» de base pour gérer tous les cas. J'espère que cela aide à éclaircir certains de mes commentaires :)
en termes d'ASP.NET MVC 2, le motif de viewModel est l'approche préférée. L'approche tire pleinement parti de la vérification du type statique de la compilation. Ceci en combinaison avec Compiler des vues MVC rendra votre flux de travail de développement beaucoup plus rapidement et plus productif, car les erreurs sont détectées lors de l'heure de la construction / compilée par opposition au temps d'exécution.
Une approche que vous voudrez peut-être envisager car votre point de vue devient plus complexe, consiste à réserver l'utilisation de modèles pour les champs de saisie et utilisez ViewData pour supporter tout ce que l'opinion doit rendre compte.
Il y a au moins quelques arguments pour soutenir ceci:
Vous avez une page principale qui nécessite des données à présenter (par exemple quelque chose comme les informations d'utilisateur Stackoverflow dans l'en-tête). L'application d'un site d'action à l'échelle du site facilite la population de ces informations dans ViewData après chaque action. Pour le mettre dans le modèle, il faudrait que tous les autres modèles du site hériteront d'un modèle de base (cela ne semblerait pas mal initialement, mais cela peut devenir compliqué rapidement).
Lorsque vous validez un formulaire publié, s'il y a des erreurs de validation, vous allez probablement refuser le modèle (avec les champs non valides) à la vue et à afficher les messages de validation. C'est bien, car les données des champs de saisie sont publiées et seront liées au modèle, mais qu'en est-il de toute autre donnée que votre vue nécessite de ré-peupler? (E.G. Les valeurs de la liste déroulante, les messages d'information, etc.) Celles-ci ne seront pas affichées, et il peut devenir en désordre de se renverser à nouveau sur le modèle "autour" les valeurs d'entrée postées. Il est souvent plus simple d'avoir une méthode qui remplit les visionneuses avec les données..View.
Dans mon expérience, j'ai trouvé que cette approche fonctionne bien.
et, dans mvc3, le dynamique Femmes de vue signifie plus d'indexation de string!