2012-02-08 14 views
34

He visto muchas publicaciones sobre cuándo usar ViewBag/ViewData vs ViewModel, pero no he podido encontrar una explicación del ciclo de vida de ViewBag.ViewBag/ViewData Lifecycle

Por ejemplo, tengo dos métodos de acción en un controlador:

// POST: /MyModel/Edit/5 
[HttpPost] 
public ActionResult Edit(MyModel _mymodel){} 

y

// GET: /MyModel/Edit/5 
public ActionResult Edit(int id){} 

si pongo algunos valores en el ViewBag en el método de acción GET, para configurar de alguna forma etiquetas, luego cuando el usuario hace clic en el botón 'Enviar' y el formulario se envía de vuelta al servidor a través de HTTP POST, los valores ViewBag ya no están dentro del método de acción POST.

¿Puede alguien explicar (o proporcionar una referencia al buen artículo) el ciclo de vida de ViewBag/ViewData?

Respuesta

35

Los datos que ingresa en ViewBag/ViewData solo están disponibles durante el ciclo de vida de la solicitud dentro de la cual lo rellenó. MVC no tiene publicaciones posteriores. Si necesita que algo persista en más de una solicitud, debe usar Session.

Aquí es un artículo decente sobre las diferencias entre ViewData, ViewBag y TempData: http://rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications

+0

gracias por la respuesta. Había leído ese artículo y no toca el ciclo de vida de ViewBag/ViewData, pero lo hace ligeramente en TempData. Para aclarar las cosas, por 'Publicar Atrás' todo lo que quise decir es que el usuario envía un FORMULARIO causando una Solicitud HTTP POST, que luego se maneja mediante un método de Acción apropiado de los Controladores. – JTech

+1

El artículo establece "Sin embargo, una vez que el controlador redirige, ViewBag y ViewData contendrán valores nulos". Correcto, ella no dice específicamente que el ciclo de vida de ViewBag y ViewData finaliza una vez que se completa la solicitud, pero ella lo insinúa. –

2

De MSDN - ViewBag: El diccionario de vista de datos dinámica, ViewData: El diccionario de los datos de vista.

Entonces estos/esto es un diccionario para una vista determinada. Usted establece sus valores en su acción y los usa en su vista. Como Zach dijo que no regresaría con la solicitud posterior. Puede enviar sus valores de regreso a cualquier acción dada como un campo de formulario, en la cadena de consulta, etc., pero estos valores no estarán disponibles automáticamente como propiedades de VieBag.

0

ViewBag y ViewData se utilizan para el mismo propósito. Se usan para pasar datos de los controladores a la Vista. Cuando les asignamos cualquier dato u objeto, están accesibles en la Vista.

  • ViewData: ViewData es un diccionario de objetos y son accesibles por cadena como clave.
  • ViewBag: utiliza la función dinámica. Permite que un objeto le agregue propiedades dinámicas .
+0

Esto no es verdad. ¿Por qué crees que hay 2? ViewBag es una bolsa de propiedades dinámica para la vista en sí, como título de página, datos de localización, como etiquetas, y puede cambiar si la acción de su controlador presenta diferentes vistas, como web/móvil, etc., y los usuarios deben cambiar de idioma. ViewData es el Modelo, los datos se pasan a la vista para rellenar la página con datos, como rellenar controles de entrada con valores o algunos datos de respuesta del usuario. –

7

La respuesta aceptada aquí realmente no describe el ciclo de vida de ViewBag/ViewData. Es desafortunado que parece no haber documentación clara sobre esto. Sin embargo, en base a esto:

http://blogs.msdn.com/b/varunm/archive/2013/10/03/understanding-of-mvc-page-life-cycle.aspx

Parecería el ciclo de vida es: solicitud

IIS -> Routing -> MVC Handler -> Controlador (con ViewData) -> View (con ViewData) - > Eliminación

Por lo tanto, ViewData (que ViewBag simplemente ajusta) se instanciaría realmente con ControllerContext, al mismo tiempo que se crea una instancia de TempData. Esto ocurre unos pocos pasos después del Paso 4: MVC Handler Executes.

Hay un paso interesante más adelante en el que "Si la página tiene ViewData, ViewData se establece" durante el traspaso de Controller a View. ViewData está claramente disponible antes de esto, por lo que establecer no puede significar instanciar. Por el contrario, parece que se transfiere del Controlador (que recuerda no está disponible para una Vista) al ViewContext (el contenedor que proporciona acceso de Vista a ViewBag/ViewData, y Model).

Aparentemente, el ViewData se descarta al mismo tiempo que el resto de la Vista.

También es importante tener en cuenta que las vistas MVC se representan desde adentro hacia afuera, por lo que la vista particular y las asignaciones que haga al ViewBag también ocurrirán en el interior o en el exterior. Eso significa que algo configurado en una página secundaria Vista estará disponible para un Diseño, pero agregar algo a un ViewBag en un Diseño y luego leerlo en una página secundaria Vista fallará.

Cuestiones relacionadas