Pourquoi tout le monde déteste ViewData?

Question

Je me demande, pourquoi tout le monde hates ViewData? Je trouve cela très utile et pratique. Je vous dis pourquoi: typiquement chaque action de contrôleur a son propre ViewModel, donc il est utilisé une seule fois et je trouve très fastidieux de modifier la classe ViewData chaque fois que j'ai besoin d'ajouter une portion de données à afficher. modifier son constructeur). Au lieu de cela, je peux écrire dans le contrôleur

ViewData["label"] = someValue; 
// in mvc 3 even better: 
ViewData.Label = someValue 

et vue

<%= ViewData["label"] %> 
<%-- mvc 3: --%> 
<%= ViewData.Label %> 

ou pour les types complexes:

<% ComplexType t = (ComplexType)ViewData["label"]; %> // and use all benefits of strong typing 
<%= t.SomeProperty %> 

Rédaction d'une action du contrôleur, je ne dois pas passer à une autre classe, lorsque Je dois ajouter quelques données à voir. Et un gros plus pour moi: ne pas inonder votre projet avec des classes insensées et basculer entre eux et les autres.
Je suis d'accord que l'utilisation de "chaînes magiques" pourrait conduire à des erreurs qui ne sont pas attrapées par le compilateur, mais ces erreurs localisées dans une très petite partie du code et peuvent être découvertes très rapidement. D'ailleurs, comment pensez-vous que les gars qui travaillent avec des langages dynamiques (rails, django) vivent sans avoir à taper du tout?)

Comment jugez-vous l'utilisation de ViewData?

Answer 1

Je pense que cela va au-delà de l'argument de la chaîne magique. Je dirais que ViewModels est une bonne chose et non des classes insensées, car elles aident à garder les vues plus propres et plus faciles à lire qu'à accéder à ViewData partout dans les vues.

Lorsque vous obtenez cinq, dix, vingt éléments de données qui doivent être affichés dans une vue, allez-vous vraiment transmettre toutes ces données en tant que ViewData? Cela rendra votre vue plus difficile à suivre et ces données n'auront aucune signification. Créer un ViewModel et taper fortement la vue sur ce ViewModel ne rendra pas seulement le code plus facile à lire, mais vous n'aurez pas à lancer des objets ViewData partout dans votre code.

Je pense que ViewData est bon pour certains cas, mais quand vous avez affaire à beaucoup de données, vous pouvez facilement en abuser.

Answer 2

Weeellll .....

Pourquoi ne pas écrire des classes de cette façon?

public dictionary<string, object> myCollectionOfClasses; 
myCollectionOfClasses.Add("MyClass", new MyClass); 

public class MyClass 
{ 
    public string DoSomething 
    { 
     return "SomeString"; 
    } 
} 

Vous devez les appeler ainsi:

string myString = myCollectionOfClasses["MyClass"].DoSomething(); 

Maintenant, ce qui est plus bête?

Voir aussi
How we do MVC – View models

Answer 3

tout d'abord, impressionnant +1 pour me laisser savoir comment MVC3 fait vidéotex! Je voulais trouver un moyen de faire quelque chose comme ça dans MVC2.
En ce qui concerne pourquoi viewdata est mauvaise? Je ne pense pas que ce soit aussi longtemps qu'il est utilisé de façon clairsemée et est testé dans les attentes. 1) L'échec de l'inclusion de viewdata entraîne des exceptions sur une vue qui ne sont pas interceptées par le compilateur. Je me suis aidé avec ce problème en ne pas utiliser la plus voûtée modèle T4MVC (altho je le recommande) et au lieu « écrire » quelque chose me similaire:

 /// <summary> 
     /// Main Greeting 
     /// ViewData: ViewDataConstants.Message 
     /// </summary> 
     public const string Index = "~/Views/Home/Index.aspx"; 

Avec cela, mon IntelliSense me donnera une tête quand je retourne this.View (ViewConstants.Home.Index); Si je connaissais assez T4 pour modifier T4MVC pour faire cela pour moi, je retournerais à ce que cela soit généré;)

2) Les typos sont une douleur. C'est pourquoi, comme vous le verrez ci-dessus, j'utilise une classe statique non seulement pour les noms de vue, mais aussi pour les indexeurs de données de visualisation.Quand je ne l'utilise vidéotex, vous verrez le code comme ceci dans ma page:

<%: ViewData[ViewDataConstants.Message] %> 

Si vous pouvez garder ces deux points de douleur en échec, et de garder l'utilisation à un niveau faible acceptable, vidéotex a ses avantages et devrait ne pas être négligé.