Perché tutti odiano ViewData?

Question

Mi chiedo, perché tutti hates ViewData così tanto?
Lo trovo abbastanza utile e conveniente. Vi dico perché: in genere ogni azione del controller ha il proprio ViewModel, quindi viene usata solo una volta e trovo molto noioso modificare la classe ViewData ogni volta che ho bisogno di aggiungere una porzione extra di dati da visualizzare (aggiungendo un campo aggiuntivo alla classe di solito porta a modificando il suo costruttore). Invece posso scrivere nel controllore

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

e in vista

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

o per tipi complessi:

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

Scrivi azione di controllo non devo passare ad un'altra classe, quando Ho bisogno di aggiungere alcuni dati per la visualizzazione. E un grande più per me: non allagare il tuo progetto con classi prive di senso e il passaggio tra loro e gli altri.
Sono d'accordo che l'uso di "stringhe magiche" potrebbe portare a errori che non vengono catturati dal compilatore, ma questi errori sono localizzati in una parte molto piccola del codice e possono essere scoperti molto rapidamente. Inoltre, come pensi che i ragazzi che lavorano con linguaggi dinamici (rotaie, django) vivano senza una forte digitazione?)

Qual è la tua opinione sull'utilizzo di ViewData?

Answer 1

Penso che questo vada oltre l'argomento della stringa magica. Direi che ViewModels è una buona cosa e non classi prive di senso perché aiutano a mantenere le viste più pulite e più facili da leggere rispetto all'accesso a ViewData su tutte le viste.

Quando si arriva a cinque, dieci, venti pezzi di dati che devono essere visualizzati in una vista, si passa davvero tutti i dati come ViewData? Renderà più difficile seguire la tua visione e i dati non avranno alcun significato. Realizzare un ViewModel e digitare fortemente la vista su quel ViewModel non solo renderà il codice più facile da leggere, ma non dovrai più lanciare gli oggetti ViewData su tutto il tuo codice.

Penso che ViewData sia buono per alcuni casi, ma quando si hanno a che fare con molti dati può essere facilmente abusato a mio parere.

Answer 2

Weeellll .....

Perché non si scrive le classi in questo modo?

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

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

Si dovrebbe chiamare loro in questo modo:

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

Ora che è più sciocco?

Vedi anche
How we do MVC – View models

Answer 3

Prima di tutto, impressionante +1 per avermi fatto sapere su come MVC3 fa viewdata! Volevo trovare un modo per fare qualcosa del genere in MVC2.
Per quanto riguarda perché viewdata è male? Non credo che sia così lungo come viene usato scarsamente E è testato per le aspettative. Esistono due punti critici principali per l'utilizzo di viewdata:

1) La mancata inclusione di viewdata causa eccezioni su una vista che non vengono catturate dal compilatore. Io stesso ho aiutato con questo problema non usando il tanto a volta modello T4MVC (ma nemmeno Lo raccomando) e invece "scrivere" qualcosa di simile me stesso:

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

Usando questo, il mio intellisense mi darà un testa a testa quando restituisco this.View (ViewConstants.Home.Index); Se conoscessi abbastanza T4 per alterare T4MVC a fare questo per me, tornerei ad avere questo generato;)

2) I dattilografi sono un dolore. Ecco perché, come vedrai sopra, utilizzo una classe statica non solo per i nomi delle viste, ma anche per gli indicizzatori di viewdata.Quando uso viewdata, vedrete il codice come questo nelle mie pagine:

<%: ViewData[ViewDataConstants.Message] %> 

Se si riesce a mantenere quei due punti di dolore sotto controllo, e mantenere l'utilizzo ad un livello basso accettabili, viewdata ha i suoi vantaggi e dovrebbe non essere trascurato.