¿Mejores prácticas para el flujo de trabajo de aplicaciones web?

Question

Nota: Por flujo de trabajo no me refiero a la tecnología de flujo de trabajo, como la base de flujo de trabajo.

Demasiado a menudo me veo obligado a diseñar páginas que fluyen a través de una serie de pasos.

1) Seleccione de un conjunto de opciones. Enviar. 2) Completa una página con resultados. Hacer cambios. Enviar. 3) Haga algo basado en los resultados anteriores. Enviar. 4) Confirmar acciones anteriores. Enviar. 5) Ir a 1.

Un sitio de comercio electrónico con carrito de compras sería un ejemplo de libro de texto de esto.

Ahora, hay varias maneras de lidiar con esto. Mi pregunta es, ¿cuál es la forma recomendada de hacerlo en asp.net? En PHP o ISAPI solo usaría controles html estándar, obtendría los datos de la publicación y haría cosas con ella, cada uno en una página diferente.

ASP.NET parece estar más orientado a soluciones de una sola página. Haga su trabajo, devuélvala a usted mismo, luego muestre sus resultados en la misma página ... avanzando hasta el final, usando algo como MultiView o UpdatePanels para hacer el trabajo. Pero la clave es que no se transfiere a otra página.

Ahora entiendo que Microsoft ha agregado devoluciones de páginas cruzadas a .NET en versiones recientes, pero esto parece menos horneado y algo engorroso. Es difícil trabajar con datos que se publicaron a menos que lo expongas a través de propiedades o algo de tu página anterior.

¿Cómo manejas el escenario que expuse arriba? ¿Utiliza una vista múltiple o un panel de actualización y lo hace todo en una sola página? ¿O lo haces en varias páginas? ¿Cuáles son sus mejores prácticas en este sentido? ¿Tiene algún diseño específico que tienda a usar? ¿Cómo se estructura el flujo de trabajo de los sitios?

Answer 1

hay un número de maneras de hacerlo (además de múltiples vistas):

1, asp.net dosis apoyo posterior a la acción, gafa Page.Request.Form[item]http://msdn.microsoft.com/en-us/magazine/cc164151.aspx#S3

2, puede guardar los datos temporales en tabla temporal de la base de datos, cuando los usuarios revisan cada página, todo lo que necesitan hacer es hacer referencia a la ID de datos temporales en la base de datos. (Query String)

3, también podrá guardar sus datos temporales como un objeto en su sesión, de modo que todas sus páginas en el "flujo de trabajo" puedan hacer referencia a la sesión y luego manipularla en función de ella.

después de todo, todos tienen sus pros y sus contras, depende principalmente de qué tan complejos sean los requisitos de su proyecto.

Answer 2

Para este tipo de situaciones, he usado varios controles de panel para contener los diversos pasos del proceso. Establezca la propiedad visible para mostrar la UI de la parte que desea que el usuario vea.

Es posible que también desee ver el Wizard Web Server Control que maneja las tuberías para navegar entre los pasos del proceso. Para obtener algunas ideas sobre cómo funciona el control, consulte The ASP.NET 2.0 Wizard Control.

Answer 3

Mystere Hombre, leí su pregunta preguntando cómo lo hacemos. Para mí, tengo una palabra: Contexto. Mantenlo en contexto. Lo explicaré.

Puede construir una aplicación web completa desde una página si lo desea.Técnicamente es posible, aunque sería tan confuso como todos salen. Agrupe mi funcionalidad en piezas lógicas como "Seleccionar un producto". Solía ​​hacer una sola página agrupando el proceso "Checking Out", pero desalentador que ahora como mi equipo ha tenido que saltar en el proceso en un punto específico como agregar automáticamente productos al carrito de compras y luego mostrar la página final en el proceso de pago. (piense en obtener una descarga gratuita: no necesita información de envío, formación de facturación ni su nombre). Con su lista numerada arriba, si todo está en la función, la convertiría en una página física, pero la dividiría en varias páginas si resulta que tengo que "saltar" en el flujo. Si lo convierte en una página, necesita límites claros.

No uso la publicación cruzada. Me gusta usar controladores de vista múltiple. Para mí, es importante identificar claramente qué necesita cada vista para que esté activo. En mi evento de carga de página, tengo una llamada a un método que analiza las variables de consulta o de sesión o las cookies (estos son mis contenedores de retención de estado) y, en función de lo establecido, activo una vista. No hay más código en la carga de la página, en su lugar, utilizo el evento de carga de la vista para ser mi carga de pseudo página. Codigo lo que se supone que debe hacer esa vista específica.

Con este enfoque, creo que el patrón MVC de ASP.NET es hacia donde debería ir.