¿Cuál es la lógica de hacer de ViewBag un objeto dinámico en ASP.NET MVC 3?

7

La última vez que verifiqué C # fue amado por muchos porque es un lenguaje estático, pero la introducción de ViewBag en ASP.NET MVC 3 trae el mismo problema que con las cadenas: en un controlador, escribe una cosa y en la vista por error puede escribir otra cosa.

¿Cuál es la razón para hacer que ViewBag sea dinámico? ¿Cómo es mejor?

    
pregunta Muhammad Hasan Khan 16.04.2011 - 23:59

4 respuestas

7

Es azúcar sintáctica, básicamente. No creo que esté destinado a ser funcionalmente "mejor" que el antiguo ViewData dictionary, solo que mucho menos detallado para trabajar. En lugar de sacar cosas del diccionario y lanzarlas manualmente (y bloquearlas si están equivocadas), puedes usarlas sin verborrea adicional (y fallar si están equivocadas).

Aquí es una publicación de blog que tiene algunos ejemplos de código "antes y después" que utilizan el antiguo diccionario ViewData y la nueva dinámica ViewBag . En particular, vea la iteración de foreach a través de la lista de cadenas.

foreach (var color in ViewData["listColors"] as List<string>)

... se convierte ..

foreach (var color in ViewBag.ListColors)

Editar: ¡Martinho hace un punto excelente! La nueva versión probablemente debería declarar explícitamente un string en lugar de un var , así:

foreach (string color in ViewBag.ListColors)

Dos razones:

  1. Si lo has entendido mal, por ejemplo. ViewBag.ListColors es un List de System.Drawing.Color objetos, obtendrá un error claro y inmediato, Cannot convert type 'System.Drawing.Color' to 'string' , en lugar de resultados extraños e indeseados.
  2. Si declara color como var , la inferencia de tipo lo inferirá como dynamic , por lo tanto, todo el uso de este en el bucle pasará por el enlace tardío de Dynamic Language Runtime, ¿verdad? Seguramente este es un golpe de rendimiento innecesario?
respondido por el Carson63000 17.04.2011 - 00:07
2

Como alternativa al diccionario ViewData, no se pierde mucho al hacer que ViewBag sea dinámico. De todos modos, ya estaba lidiando con un lío de cosas sin tipo: no hay ninguna desventaja real al eliminar parte del espacio para acceder a las propiedades de ViewData.

Si desea realizar una comprobación de tipo (y una IMO de interacción limpiador / vista más limpia), no se le impide utilizar vistas tipográficas.

    
respondido por el Ryan Brunner 30.06.2011 - 15:11
2

Hay una ventaja operativa: debería ayudar a evitar que se ejecuten excepciones de referencia nulas extrañas.

Digamos que estoy buscando una cerveza en mi bolsa de vista, pero olvidé ponerla.

var beer = ViewBag["Beer"] as Beer;

Me da una referencia nula. Por lo tanto, cuando llamo a beer.Drink() , obtengo una excepción de referencia nula que necesito retroceder en la cadena para averiguar.

Si escribes el código como

var beer = ViewBag.Beer;

Y se olvidó de agregar la cerveza, se producirá un error en esa línea y la causa será un poco más obvia.

    
respondido por el Wyatt Barnett 30.06.2011 - 15:29
0

Respuesta corta: para hacerlo más parecido a Ruby y recuperar a las personas que abandonaron MVC para Rails.

Respuesta larga (er): estoy bastante seguro de que tiene que ver con la flexibilidad de MVC y el hecho de que el marco de trabajo de MVC ya hace que uses C # de una manera ligeramente más dinámica que el antiguo modelo de WebForms.

    
respondido por el Wayne Molina 30.06.2011 - 15:05

Lea otras preguntas en las etiquetas