ASP.NET MVC: paso de datos a través de Vistas

Question

Estoy creando una aplicación MVC. Una de mis tareas es construir una tienda. Configuré un "asistente" como un conjunto de vistas que lleva al usuario a completar diferentes tipos de datos hasta el final de la operación, en un total de 7 pasos.

Mi problema es cómo compartir algunos datos entre todas estas vistas.

Primero utilicé el anticuado Session y todo funcionó en mi escritorio, pero cuando finalmente implementé mi aplicación en el servidor de alojamiento de mi compañía obtuve excepciones porque Session se borró aleatoriamente durante algunos pasos.

Ahora modifiqué todo para configurar los datos que necesito dentro de TempData, y actualicé todos los datos en cada paso y parece que funciona correctamente.

¡Estoy un poco confundido!

Mi confusión es sobre todas estas estructuras: Sesión (sé que viene de asp.net), ViewData, TempData y la magia ViewBag.

He leído mucho sobre pero necesito que alguien me diga claramente qué es más apropiado para mí en este caso.

Answer 1

Diría que el ViewBag es perfecto para algo como esto. Ahora, te refieres al ViewBag como un viewbag "Mágico", pero en realidad solo envuelve el ViewData que es un diccionario de <string,object>

La forma en que funciona el ViewBag es que es solo un contenedor dinámico alrededor de ViewData, así que cuando pides algo, digamos ViewBag.ShoppingCart, básicamente pregunta al diccionario subyacente si tiene una entrada llamada "ShoppingCart", y devuelve el artículo.

ACTUALIZACIÓN Problema es que no recuerdo que ViewBag y ViewData son específicos de la vista, por lo que se vacían siempre que se golpea una vista/acción diferente.

A menos que necesite el ShoppingCart (o mago-curso) que se almacena en una base de datos, me gustaría ir a ViewBag TempData en su caso :)

También puede echar un vistazo a este artículo de Rachel Apple por un poco más de información sobre los tres:

http://rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications

(Sal me gustaría recomendar la lectura de los comentarios tan bien en ese puesto a obtener algunas opiniones más imparciales.)

Answer 2

Tiene varias opciones aquí: Use la sesión, viewdata (o viewbag) pero necesita pasarla usando campos ocultos o cookies.

Viewdata tiene el problema que le dará más trabajo.

Me gustaría ir con la sesión, pero tal vez se borre en su caso porque probablemente tenga más de un servidor y cuando la segunda solicitud llegue a otro servidor, simplemente no tendrá los datos del paso anterior.

Resuelva este problema utilizando un servidor que tenga la sesión para todos los servidores o use cookies (si la información NO es crítica).

Answer 3

Nada de malo con el uso de campos ocultos, en mi libro, al menos.

Solucionaré el problema de la sesión en lugar de intentar escribir el código alrededor del problema. Ejecute una prueba simple: cambie su proveedor de sesión a SQL, desactive los campos ocultos y vea si su aplicación funciona correctamente. Si no lo hace, hay otros problemas (más grandes) de los que debe preocuparse.

¿Se supone que esta aplicación debe funcionar en una granja web/"nube"/detrás de un equilibrador de carga? Si es así, debe:

• cambiar el proveedor de sesión a otra cosa: SQL, StateServer, Memcache, etc. No son necesarios muchos cambios de código.

http://msdn.microsoft.com/en-us/library/ms178587.aspx y http://memcachedproviders.codeplex.com/

O

• re-diseñar sus pasos del asistente y reducir su dependencia de los valores compartidos entre los puntos de vista. ID de sesión es todo lo que necesita y puede consultar el DB para cualquier otra cosa. No muy rápido pero seguro y estable.

Optimizar: Utilice tantos campos ocultos como desee para reducir el número de consultas de base de datos (como he dicho, no hay nada malo en esto) pero por lo general un campo es suficiente para mantener su estado serializado entre las solicitudes: http://blog.maartenballiauw.be/post/2009/10/08/Leveraging-ASPNET-MVC-2-futures-ViewState.aspx.

Incluso si no tiene que preocuparse por varias instancias de su aplicación (en máquinas diferentes), IIS recicla los procesos de trabajo de vez en cuando. Cuando lo hace, puede terminar con dos instancias ejecutándose al mismo tiempo (durante pequeñas cantidades de tiempo) en la misma máquina y algunos de sus usuarios podrían tener la mala suerte de golpear el servidor exactamente durante esos momentos.

No debería importar si la próxima solicitud llega a una instancia diferente de su aplicación. Siempre trate de diseñar con este objetivo en mente.

Espero que ayude!