Mejores prácticas/diseño para un formulario de varias páginas en .NET MVC3

Question

Estoy trabajando en una aplicación web que implica que el usuario complete un formulario de varios pasos que abarca varias páginas. El formulario tiene navegación con pestañas en la parte superior (estos enlaces no envían la página actual) y un siguiente botón en la parte inferior (que envía). Estoy considerando varias estrategias para el manejo de formulario de presentación/validación: Método

1. una acción y la vista por página de formulario. Cuando pulse siguiente, envía el formulario al método de acción para la página siguiente. Si hay errores de validación, se le redirige a la página anterior:

   • de URL son descriptivos y puede ser distribuido, copiado-pegado
   • Sólo vuelve a dirigir en el caso de error
   • Desde la redirección no tiene la forma de datos, se pierde el contexto de la presentación que hace que sea difícil de visualizar ciertos mensajes de error
   • la misma lógica de validación trabaja para redirigir al usuario si intentan visitar un paso en el flujo que no están listos para todavía

2. un método de acción y vista por página de formulario. Cuando presiona siguiente, envía el formulario a la acción de la página actual. Si hay errores de validación, se devuelve la misma vista. De lo contrario, redirigimos a la acción siguiente página:

   • de URL son descriptivos y se puede copia pegada-
   • redirecciones son muy comunes (no estoy seguro si esto es malo)
   • Cuando se muestran los errores de validación, estamos en la misma petición que el envío del formulario por lo que tenemos acceso completo a la entrada no válida
   • tienen que pasar un contexto adicional si queremos que la capacidad de, por ejemplo, añadir un botón "Anterior", que también presenta

3. un método de acción para TODAS las páginas. Las URL contienen un contexto adicional sobre el paso que se envía (por ejemplo, MyController/MyAction/{step}). El mensaje del controlador selecciona la página de visualización para regresar dependiendo de la validación y el paso actual.

   • URL no son descriptivos (por ejemplo, si presento el paso 1 para ir al paso 2, a continuación, la URL que ve el usuario será el mismo, independientemente de si se devuelve la página 1 (no válido) o en la página 2
   • n redirige
   • Cuando se muestran los errores de validación, estamos en la misma petición que el envío del formulario por lo que tenemos acceso completo a la entrada no válida

4. Un método diferente que no he enumerado aquí

me han tratado de enumerar lo que veo como algunos de los pros y los contras de cada método, pero me interesaría saber:

• ¿Cuáles son otras ventajas y desventajas de estos métodos? ¿Son los míos correctos? ¿Podrían diseñarse algunos de los contras que he enumerado?
• ¿Hay un enfoque estándar para este problema que debería estar usando?Si es así, ¿por qué es el enfoque estándar?

Answer 1

Recomendaría la opción 2 con una pequeña modificación. También puede pensar en crear también un modelo de vista por acción/vista. Si tiene un modelo que abarca todas las páginas, la validación se realizará en TODAS las propiedades, lo que significa que, aunque el usuario solo puede editar parte del modelo en cada pantalla, podría recibir advertencias de validación para las propiedades que no puede ver. Hicimos esto recientemente en un proyecto y funcionó maravillosamente. Tienes que hacer algo de manipulación de datos en el back-end para combinar todo de nuevo, pero valió la pena al final.

Como dijiste, tus URL serían enlazables, lo que significa que los usuarios pueden copiar/pegar y, lo que es más importante, pueden agregar la página como favorito en su navegador, permitiéndoles volver al mismo lugar muy fácilmente. En mi opinión, esto hace que la opción 3 sea obsoleta.

También se beneficiará del hecho de que toda su lógica de navegación se produce en un solo lugar. Deberá almacenar el estado del "asistente" en el cliente (en qué página se encuentra actualmente) para que su controlador sepa qué hacer al enviarlo. Deberá analizar el estado del asistente y tomar una decisión sobre a dónde debe dirigirse el usuario. Si opta por la opción 1, no sabrá de dónde vino y los errores de validación del servidor serán difíciles de mostrar al cliente. Este es un bello ejemplo del patrón POST - REDIRECCION - GET. Cada página tendría 2 acciones, un GET que toma identificadores simples, y un POST que toma modelos más complejos. Publique el servidor, descubra a dónde ir luego, redirija a un GET.

Por último, considere su botón anterior simplemente vinculando directamente al paso anterior, en lugar de enviar el formulario. De lo contrario, el usuario podría atascarse en un paso no válido. Esto nos sucedió a nosotros y otra vez, funcionó muy bien.

Espero que esto haya sido útil. ¡Buena suerte!