¿Cuándo es correcto usar ViewData en lugar de ViewModels?

Question

Suponiendo que desea desarrollar sus Controladores para que use un ViewModel para contener datos para las Vistas que renderiza, ¿deberían contener todos los datos dentro del ViewModel? ¿Qué condiciones sería correcto omitir ViewModel?

La razón por la que pregunto es que estoy en una posición en la que parte del código está usando ViewData y otro está usando ViewModel. Quiero distribuir un conjunto de pautas en el equipo sobre cuándo es correcto usar ViewData y cuándo solo está tomando atajos. Me gustaría recibir opiniones de otros desarrolladores que hayan tratado con esto para que yo sepa que mis directrices no son solo yo parcial.

Answer 1

Solo para seguir el comentario de Fabian; puede asegurarse explícitamente de que viewdata nunca se use siguiendo los pasos descritos en this article. Realmente no hay excusa no para usar modelos para todo.

Si no tiene más remedio que usar ViewData (por ejemplo, en un proyecto existente); como mínimo, use constantes de cadena para resolver los nombres y evitar el uso de "cadenas mágicas". Algo similar a: ViewData[ViewDataKeys.MyKey] = myvalue; De hecho, lo utilizo para todo lo que debe estar "basado en cadenas" (claves de sesión, claves de caché, claves de caché de salida VaryByCustom, etc.).

Answer 2

Personalmente, nunca utilizo ViewData, todo pasa por el Modelo, excepto cuando estoy probando algo y rápidamente necesito poder ver el valor de la vista. Strongtyping!

Answer 3

En términos de ASP.NET MVC 2, el modelo de ViewModel es el enfoque preferido. El enfoque aprovecha al máximo la verificación del tipo estático en tiempo de compilación. Esto en combinación con compiling mvc views hará que su flujo de trabajo de desarrollo sea mucho más rápido y más productivo ya que los errores se detectan durante el tiempo de compilación/compilación en lugar de en el tiempo de ejecución.

Answer 4

Un enfoque que puede considerar a medida que sus vistas se vuelven más complejas, es reservar el uso de Modelos para campos de entrada, y usar ViewData para soportar cualquier otra cosa que la Vista necesite representar.

Hay por lo menos un par de argumentos para apoyar esta:

1. Tienes una página maestra que requiere algunos datos para estar presentes (por ejemplo, algo así como la información de los usuarios stackoverflow en la cabecera). Al aplicar ActionFilter en todo el sitio, es fácil completar esta información en ViewData después de cada acción. Ponerlo en modelo requeriría que cada otro modelo en el sitio herede de un modelo base (esto puede no parecer malo inicialmente, pero puede complicarse rápidamente).

2. Cuando está validando un formulario publicado, si hay errores de validación es probable que desee volver a vincular el modelo (con los campos no válidos) a la vista y mostrar los mensajes de validación. Esto está bien, ya que los datos en los campos de entrada se publican y se vincularán al modelo, pero ¿qué pasa con cualquier otro dato que su vista requiera volver a poblarse? (por ejemplo, valores de listas desplegables, mensajes de información, etc.). No se publicarán de nuevo, y puede volverse desordenado volviendo a llenarlos en el modelo "alrededor" de los valores de entrada publicados. A menudo es más simple tener un método que rellene ViewData con los datos de la vista.

En mi experiencia, he encontrado que este enfoque funciona bien.

Y, en MVC3, ¡dynamic ViewModels significa no más indexación de cadenas!