tag - Post Redirigir Obtener en ASP.NET MVC y validación con URLs de descanso
asp.net mvc form (3)
A pesar de que la respuesta de Ken resalta un hecho importante (PRG no significa necesariamente "devolver ciegamente una redirección al publicar"), es posible que desee redireccionar y preservar a veces el estado del modelo.
La forma más fácil de manejar ese escenario, es usar filtros de acción para exportar modelstate a la sesión (antes de redireccionar), y luego importar modelstate (antes de ejecutar la nueva acción). Kazi Manzur Rashid tiene un par de excelentes publicaciones en el blog ( Parte 1 Parte 2 ) sobre las mejores prácticas en ASP.NET MVC. Son bastante viejos, pero muchos de los consejos todavía son muy aplicables. La punta número 13 en el primer artículo es exactamente lo que estás buscando.
Tengo una URL tranquila para la acción de editar una página. Esto se implementa en el controlador como un método de edición, que acepta solicitudes GET y un método de edición que acepta solicitudes POST.
Esto significa que puede visitar la URL de edición y mostrará un formulario para un GET o guardar un formulario para un POST.
[HttpGet]
public ActionResult Edit(int id) {
...
}
[HttpPost]
public ActionResult Edit(EditModel model) {
...
}
El patrón Post-Redirect-Get (PRG) parece bastante blanco y negro, porque esencialmente redirige cada POST de nuevo a una acción GET. Sin embargo, necesito estar convencido de que esto es lo correcto a hacer.
Mi plan es que, en la acción POST, si el modelo es válido, usaré el patrón Post-Redirect-Get para enviar al usuario a una ubicación razonable (probablemente la acción de Índice o Detalles).
Sin embargo, si hay un problema de validación del modelo, todavía quiero mostrar la vista. No quiero redirigir al usuario, porque significa rellenar el modelo y ModelState en datos temporales y redirigir a la acción GET, y luego agregar lógica a la acción GET para manejar los datos temporales. Podría evitar todo esto simplemente mostrando la vista.
Sí, si el usuario presiona F5, volverá a enviar el formulario y se le presentará la "advertencia de reenvío", pero luego la misma página (pidiéndole que corrija los errores de validación). Sin embargo, parece poco probable que lleguen a F5 y tampoco existe el peligro de un doble envío, ya que el formulario simplemente fallará la validación una vez más.
Si la validación pasa, el usuario será redirigido y estará a salvo de envíos dobles.
Entonces, ¿debo implementar código adicional y datos de relleno en datos temporales para seguir estrictamente el patrón de PRG, o es más sensato utilizar el patrón de PRG cuando el formulario es válido y los datos se almacenan?
PRG es lo que hay que hacer.
Realiza un POST a la acción y, si modelstate no es válido, simplemente ''exporta'' sus datos de modelstate a una variable y redirige a la acción obtener.
Esto tiene la ventaja, a diferencia de la respuesta aceptada de que no es necesario volver a escribir el código en la acción [Publicar] para recrear la vista.
en la acción de obtener, cargue el ModelState exportado desde la publicación uno.
TempData es un excelente lugar para hacer esto, el código será algo como esto:
[HttpGet]
public ActionResult Edit(int id) {
// import model state from tempdata
...
}
[HttpPost]
public ActionResult Edit(EditModel model) {
// if modelstate is invalid
// save modelstate in tempdata
// redirect to Edit/{id}
// else
...
RedirectToAction("List")
}
esto se puede automatizar utilizando AttributeFilters, aquí hay una excelente publicación creada por @ ben-foster aquí:
Solo debe hacer la redirección si la información del formulario es válida; en el caso de errores de envío, devuelva la vista desde el mismo método de edición.
Hacerlo de esta manera es compatible con PRG, porque si su modelo no es válido, no está permitiendo que se realicen cambios en el estado de los objetos en el servidor. PRG está diseñado principalmente para evitar múltiples publicaciones que pueden cambiar el estado de los objetos del servidor (por ejemplo, objetos comerciales, tablas de bases de datos, etc.) de manera impredecible; en su ejemplo de validación, sin embargo, el usuario puede reenviar el envío tantas veces como lo desee y siempre se enviarán de vuelta a la vista inicial con errores de validación, no cambia nada en el servidor. Por lo tanto, tiene razón: solo emita la Redirección si su modelo pasa la validación en su nivel de presentación.