ASP.NET MVC - TempData - Buena o mala práctica

Question

estoy usando el método AcceptVerbs se detalla en la vista previa 5 entrada del blog de Scott Gu para hacer frente a entradas de la forma en ASP.NET MVC:

• usuario recibe un vacío formulario a través de GET
• mensajes de los usuarios del cumplimentar el formulario a través de POST a la misma acción
• la acción valida los datos, toma las medidas adecuadas, y redirige a una nueva visión

por lo tanto, no tienen 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 a usar TempData - que es algo para ser diseñado.

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

Answer 1

Pienso que los datos temporales son un mecanismo de "olvídate del fuego" 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á teniendo la acción redirigir 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 2

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

Dependiendo del diseño, siempre puede almacenar el usuario/cesta o lo que necesite en las tempdadas en la base de datos y solo tiene un campo "IsReady" que indica si está completo o no, haciéndolo extensible para más adelante si quieres tener en cuenta, que las personas pueden cerrar sus navegadores.

Answer 3

¿Por qué tiene tal aversión? Esto simplemente es hacer su trabajo y hacerlo bien :)

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

Answer 4

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.

Guarda 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 5

Creo que hace bien en dudar antes de usar TempData. TempData está almacenado en la sesión y esto puede tener implicaciones para usted si:

1. Usted no utiliza sesiones en su sitio ahora
2. Usted tiene un sistema que necesita para escalar a un alto rendimiento, es decir, que' d prefieren evitar por completo el estado de sesión
3. Usted no quieren utilizar cookies (no sé qué tan bien MVC soporta sesiones sin cookies en este momento)

Si su sitio tiene que tener una alta disponibilidad, entonces hay son consideraciones adicionales sobre la aplicación del estado de la sesión, pero estos son todos solvabl e problemas

Answer 6

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. Considere 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.

Products/1 es solo la acción GET estándar para el producto, pero nos gustaría que aparezca un mensaje que indique que la inserción 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 posterior, y redirigiendo a los Prod. De acción iniciales/Nuevo. Agregué lógica a la vista para llenar las entradas del formulario con los valores previamente ingresados ​​junto con los mensajes de error. ¡Me parece agradable y limpio!

Answer 7

Echa un vistazo sessionless controllers 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.

Como tempdata usa 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.

Answer 8

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 REST, 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 utilizar un enfoque de cadena de consulta si se utiliza sólo para redirigir a otra página de alertas.