example - ASP.NET MVC-TempData-Práctica buena o mala

viewbag temp

Question

Estoy utilizando el método AcceptVerbs detallado en la publicación de blog de Preview Preview 5 de Scott Gu para tratar las entradas de formularios en ASP.NET MVC:

• El usuario obtiene un formulario vacío a través de GET
• El usuario envía el formulario rellenado a través de POST a la misma Acción
• La acción valida datos, toma las medidas apropiadas y redirige a una nueva vista

Entonces no tengo que usar TempData . Dicho esto, ahora tengo que agregar un paso ''confirmar'' a este proceso, y parece requerir el uso de TempData .

Por alguna razón, tengo una aversión al uso de TempData , que es algo en lo que se debe diseñar.

¿Es esto una preocupación válida, o lo estoy inventando?

Answer 1

¿Por qué tienes tanta aversión? Esto simplemente hace su trabajo y lo hace bien :)

Si no te gusta porque no está fuertemente tipado, siempre puedes crear un envoltorio que te proporcione una interfaz fuertemente tipada.

Answer 2

Creo que debes dudar antes de usar TempData. TempData se almacena en la sesión y esto puede tener consecuencias para usted si:

1. No usa sesiones en su sitio ahora
2. Usted tiene un sistema que necesita escalar a un alto rendimiento, es decir, prefiere evitar el estado de la sesión por completo
3. No desea utilizar cookies (no sé qué tan bien MVC admite sesiones sin cookies en este momento)

Si su sitio necesita tener una alta disponibilidad, existen consideraciones adicionales sobre la aplicación del estado de la sesión, pero todos estos son problemas que se pueden solucionar.

Answer 3

Es como usar ViewData, lo que significa que probablemente no sea un riesgo de seguridad. Pero preferiría usar ViewData que TempData. Consulte aquí para obtener una comparación: http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/

Dependiendo del diseño, siempre puedes almacenar el usuario / cesta o lo que necesites en las tempdatas de la base de datos y solo tienes un campo "IsReady" que indica si está completo o no, por lo que es extensible para más adelante si quieres aprovechar tenga en cuenta que las personas pueden cerrar sus navegadores.

Answer 4

No es necesario tener aversión a TempData ... Pero si no se usa correctamente, seguramente podría ser una indicación de un diseño deficiente. Si está utilizando URL RESTful, TempData es una práctica recomendada para transferir mensajes de sus Acciones POST a sus Acciones GET. Considera esto:

Tiene un formulario en URL Products / New. El formulario Publicaciones a productos / Crear, que valida el formulario y crea el Producto, en caso de éxito, el controlador redirecciona a Productos URL / 1 y en caso de error lo redirecciona a productos / Nuevo para mostrar mensajes de error.

Productos / 1 es solo la acción GET estándar para el producto, pero nos gustaría que aparezca un mensaje que indique que el inserto fue un éxito. TempData es perfecto para esto. Agregue el mensaje a TempData en el Controlador posterior y ponga algo de lógica si en la vista y listo.

En caso de error, he estado agregando los valores ingresados ​​en formCollection y una colección de mensajes de error a TempData en la acción de publicación, y redirigiendo a los Prod. De acción inicial / Nuevo. Agregué lógica a la vista para rellenar las entradas del formulario con los valores ingresados ​​previamente junto con los mensajes de error. ¡Me parece agradable y limpio!

Answer 5

Pienso que los datos temporales son un mecanismo de disparar y olvidar para notificar al usuario. Es genial recordarles algo que hicieron recientemente, pero también dudaría en convertirlo en un paso obligatorio en algún proceso de usuario. La razón es que si actualizan la página, creo que se habrá ido. Bueno, supongo que también soy reacio a usarlo, ya que no está muy bien definido cuán confiable es.

Me pregunto si el problema es que estás redirigiendo la acción a otra página antes del paso de confirmación. Me pregunto si, en su lugar, después de que se hayan enviado por primera vez, se podría procesar lo suficiente para generar el cuadro de diálogo de confirmación y luego devolver la página original con la pregunta de confirmación. De forma similar a como podría hacer la validación, excepto que la regla de validación comprueba si se realizó el paso de confirmación (con la UI de confirmación oculta hasta que otras validaciones pasen).

Answer 6

Tengo un método GetModel que primero comprueba TempData ["modelo"] y lo devuelve. De lo contrario, GetModel carga los datos apropiados de la base de datos.

Ahorra una carga extra de la base de datos cuando tengo una acción que necesita devolver una vista diferente que requiere los mismos datos del modelo.

Answer 7

Todas las buenas respuestas, han echado un vistazo a esto para pasar mensajes a lo largo.

TempData y Session no son la mejor idea para las arquitecturas RESTful ya que la mayoría de las sesiones se almacenan en la memoria. Por lo tanto, cuando desee utilizar una granja de servidores, la sesión de los usuarios existiría en un servidor, mientras que su próxima solicitud podría enviarse a otro servidor.

Dicho esto, eche un vistazo a este uso de TempData para pasar mensajes aquí.

http://jameschambers.com/2014/06/day-14-bootstrap-alerts-and-mvc-framework-tempdata/

Mabye esto podría ser adaptado para usar un enfoque de cadena de consulta si se usa solo para redirigir a otras alertas de página.

Answer 8

Verifique los controladores sin sesión en MVC3. Resultó que esa sesión de uso evita la ejecución paralela de las solicitudes de un solo usuario y, por lo tanto, conduce a un rendimiento degradado.

Debido a que tempdata utiliza la sesión de manera predeterminada, no podrá usar esta función. Puede cambiar a usar cookies para tempdata, pero es un poco incómodo (al menos para mí). Aún más limpio que ViewState, así que tal vez no sea tan importante.