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

Estoy usando el AcceptVerbsmétodo detallado en la publicación del blog Vista previa 5 de Scott Gu para tratar las entradas de formulario en ASP.NET MVC:

• El usuario obtiene un formulario vacío a través de GET
• El usuario publica el formulario completado a través de POST en la misma acción
• La acción valida los datos, toma la acción apropiada y redirige a una nueva vista

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

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

¿Es esta una preocupación válida o me la estoy inventando?

Creo 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 desaparecerá. Bueno, supongo que también dudo en usarlo, ya que no está muy bien definido qué tan confiable es.

Me pregunto si el problema es que la acción se redirige a otra página antes del paso de confirmación. Me pregunto si, en cambio, después de que envíen por primera vez, podría realizar el procesamiento 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 manera similar a cómo podría hacer la validación, excepto que la regla de validación verifica si se realizó el paso de confirmación (con la IU de confirmación oculta hasta que se apruebe otra validación).

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 mejor práctica para transferir mensajes desde sus Acciones POST a sus Acciones GET. Considera esto:

Tiene un formulario en URL Products / New. El formulario Publicaciones en Productos / Crear, que valida el formulario y crea el Producto, en caso de éxito, el Controlador redirige a URL Productos / 1 y, en caso de error, lo redirige 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 se muestre un mensaje que indique que la inserción fue un éxito. TempData es perfecto para esto. Agregue el mensaje a TempData en el controlador de publicación y coloque algo de lógica en la vista y listo.

En caso de falla, 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 la acción inicial Prodcuts / New. Agregué lógica a la vista para completar las entradas del formulario con los valores ingresados ​​anteriormente junto con cualquier mensaje de error. ¡Me parece agradable y limpio!

Creo que debería dudar antes de utilizar TempData. TempData se almacena en la sesión y esto puede tener implicaciones para usted si:

1. No usa sesiones en su sitio en este momento
2. Tiene un sistema que necesita escalar a un alto rendimiento, es decir, preferiría evitar el estado de 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 alta disponibilidad, existen consideraciones adicionales sobre la aplicación del estado de sesión, pero todos estos son problemas que se pueden resolver.

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

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

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

Dado que tempdata usa session de forma predeterminada, no podrá usar esta función. Puede cambiar al uso de cookies para tempdata, pero es un poco incómodo (al menos para mí). Sin embargo, sigue siendo más limpio que viewstate, así que tal vez no sea un factor decisivo.

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

Si no le gusta porque no está fuertemente tipado, siempre puede crear un envoltorio que le proporcionará una interfaz fuertemente tipada.

Es como usar ViewData, lo que significa que probablemente no sea un riesgo para la seguridad. Pero prefiero usar ViewData que TempData. Consulte aquí para ver 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 los tempdata en la base de datos y solo tener un campo "IsReady" que indica si está completo o no, haciéndolo extensible para más tarde si quieres tomar en Tenga en cuenta que las personas pueden cerrar sus navegadores.

Todas las buenas respuestas, ¿ha echado un vistazo a esto para pasar mensajes?

TempData y Session no son la mejor idea para arquitecturas RESTful ya que la mayoría de las sesiones se almacenan en la memoria. Entonces, 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 adaptarse para usar un enfoque de cadena de consulta si se usa solo para redireccionar a otra página de alertas.