¿Por qué todos odian ViewData?

Me pregunto, ¿por qué todos hates ViewData tanto?
Lo encuentro bastante útil y conveniente. Te digo por qué: típicamente cada acción del controlador tiene su propio ViewModel, así que solo se usa una vez y me resulta muy tedioso modificar la clase ViewData cada vez que necesito agregar una porción adicional de datos para ver (agregar campo extra a la clase generalmente conduce a modificando su constructor). En lugar Puedo escribir en el controlador¿Por qué todos odian ViewData?

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

y en vista

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

o para tipos complejos:

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

Escribir una acción del controlador no tengo que cambiar a otra clase, cuando Necesito agregar algunos datos para ver. Y un big plus para mí: no inunda su proyecto con clases sin sentido y cambiando entre ellos y otros.
Estoy de acuerdo en que el uso de "cadenas mágicas" podría provocar errores que no son detectados por el compilador, pero estos errores se localizan en una parte muy pequeña del código y pueden descubrirse muy rápidamente. Además, ¿cómo crees que los chicos que trabajan con lenguajes dinámicos (rieles, django) viven sin una mecanografía fuerte?)

¿Cuál es su opinión sobre el uso de ViewData?

Fuente

2010-10-21 kilonet

+1 por valentía. –

Meh, él solo está tratando de pelear con consenso. - La comparación de RoR, Django no es justa. Si tiene una herramienta (el compilador) para asegurarse de que su código sea de mejor calidad, ¿por qué no usarlo? el RoR, los chicos de Django (y yo incursiono en ellos) probablemente tengan muchos errores tontos que no entiendo con C#. – jfar

Creo que esto va más allá del argumento de cadena mágica. Yo diría que ViewModels es una buena cosa y no una clase insensata porque ayuda a mantener las Vistas más limpias y más fáciles de leer que el acceso a ViewData en todas las Vistas.

Cuando llega a cinco, diez, veinte datos que deben mostrarse en una vista, ¿realmente va a pasar todos esos datos como ViewData? Hará que su vista sea más difícil de seguir y que los datos no tendrán ningún significado. Hacer un ViewModel y escribir fuertemente la vista en ese ViewModel no solo hará que el código sea más fácil de leer, sino que no tiene que ir a lanzar objetos ViewData por todo su código.

Creo que ViewData es bueno para ciertos casos, pero cuando se trata de una gran cantidad de datos, se puede abusar fácilmente en mi opinión.

Fuente

2010-10-21 15:05:42 amurra

de acuerdo con usted. Al usar grandes piezas de datos estructurados, ViewModel es un mejor lugar para ello. Pero muy a menudo ViewModel resulta ser una bolsa con diferentes datos. – kilonet

@kilonet: estuvo de acuerdo, pero al menos aún obtiene el beneficio de escribir fuertemente con ViewModels, mientras que con ViewData no lo hace. – amurra

Weeellll .....

¿Por qué no escribe las clases de esta manera?

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

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

Usted tendría que llamar a ellos de esta manera:

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

Ahora que es más tonto?

Ver también
How we do MVC – View models

Fuente

2010-10-21 14:47:19

su ejemplo no es como la situación con Vistas, Controladores y Modelos de Vista en MVC. ViewModels: es un nivel extra de código entre Vistas y Controladores. Por qué no me gusta, escribí en mi publicación y creo que usar el diccionario en mvc es una transacción razonable. – kilonet

Es solo una manera conveniente de separar la complejidad de la aplicación ... Divida y conquiste, si lo desea. Para mí, un gran beneficio de proporcionar clases de ViewModel es 1) documentar la información que se utilizará en la Vista, y 2) proporcionar un lugar para poner la lógica de la vista. No puede hacer ninguna de las dos cosas con un diccionario ViewData. Y sí, me gusta el intellisense que obtienes cuando usas un objeto ViewModel. Si parece mucho trabajo, puede usar Automapper para mapear los objetos de su modelo de dominio a sus objetos de ViewModel por usted. –

Véase también http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx –

En primer lugar, impresionante 1 por dejarme saber acerca de cómo MVC3 hace viewdata! He querido encontrar alguna forma de hacer algo así en MVC2.
¿Por qué viewdata es malo? No creo que sea tan larga como se use escasamente y se prueba en cuanto a las expectativas. Hay dos puntos importantes para usar viewdata:

1) La falla al incluir viewdata causa excepciones en una vista que no son detectadas por el compilador. He ayudado a mí mismo con este problema al no utilizar la tan abovedados plantilla T4MVC (Altho Lo recomiendo) y en lugar de "escribir" algo similar a mí mismo:

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

uso de este, mi intelisense me dará una mano a mano cuando devuelvo this.View (ViewConstants.Home.Index); Si sabía lo suficiente T4 para alterar T4MVC para hacer esto por mí, me gustaría volver a tener este generado;)

2) Typos son un dolor. Es por eso que, como verá más arriba, utilizo una clase estática no solo para ver los nombres, sino también para los indexadores de viewdata.Cuando yo utilizo viewdata, verá código como este en mis páginas:

<%: ViewData[ViewDataConstants.Message] %>

Si puede mantener esos dos puntos de dolor bajo control, y mantener el uso a un nivel aceptablemente bajo, viewdata lo tiene es ventajas y debe no se debe pasar por alto.

Fuente

2010-10-21 14:49:22 ARM

Respuesta

Cuestiones relacionadas