¿Cuál es el 'ciclo de vida de la página' de una página ASP.NET MVC, en comparación con ASP.NET WebForms?

¿Cuál es el 'ciclo de vida de la página' de una página ASP.NET MVC, en comparación con ASP.NET WebForms?

Estoy tratando de comprender mejor esta pregunta 'simple' para determinar si las páginas existentes que tengo en un sitio (muy) simple se pueden convertir fácilmente desde ASP.NET WebForms.

Ya sea una 'conversión' del proceso a continuación o un ciclo de vida alternativo sería lo que estoy buscando.

Lo que estoy haciendo actualmente:

(sí, sé que cualquier persona capaz de responder mi pregunta ya sabe todo esto, solo estoy tratando de obtener una comparación del 'ciclo de vida', así que pensé que comenzaría completando lo que ya todos sabemos)

Renderizando la página:

• Tengo una página maestra que contiene mi plantilla básica.
• Tengo páginas de contenido que me dan regiones con nombre de la página maestra en la que pongo contenido.
• En un controlador de eventos para cada página de contenido, cargo datos de la base de datos (principalmente de solo lectura).
• Ato estos datos a controles ASP.NET que representan cuadrículas, menús desplegables o repetidores. Todos estos datos 'viven' dentro del HTML generado. Algo de eso entra en ViewState (¡pero no entraré en eso demasiado!)
• Establezco propiedades o enlazo datos a ciertos elementos como los controles Image o TextBox en la página.
• La página se envía al cliente representada como HTML no reutilizable.
• Trato de evitar usar ViewState aparte de lo que la página necesita como mínimo.

Lado del cliente (sin usar ASP.NET AJAX):

• Puedo usar JQuery y algunos trucos desagradables para encontrar controles en la página y realizar operaciones en ellos.
• Si el usuario selecciona de un menú desplegable, se genera una devolución de datos que desencadena un evento C # en mi código detrás. Este evento puede ir a la base de datos, pero haga lo que haga, una página HTML completamente nueva termina siendo enviada de regreso al cliente.
• Puedo usar Page.Session para almacenar pares de valores clave que necesito reutilizar más tarde

Entonces, con MVC, ¿cómo cambia este 'ciclo de vida'?

Intentaré comentar cada uno de los puntos que mencionaste:

Sus páginas maestras todavía existen en MVC y se utilizan para proporcionar un diseño coherente al sitio. No hay mucho nuevo allí.

Sus páginas de contenido se convertirán en vistas en el mundo MVC. Todavía proporcionan las mismas áreas de contenido a sus páginas maestras.

El manejo de eventos de formularios web no debe usarse en MVC, en cambio, sus clases de Controlador y sus métodos de acción manejarán la carga de sus datos en un "modelo" que se pasa a la vista.

Aunque el enlace de datos de estilo de formulario web es posible en MVC, creo que no es la solución óptima. Es mejor colocar sus datos en una clase de modelo y escribir fuertemente su vista para que tenga acceso directo a ese modelo. Entonces es simplemente una cuestión de usar el<%= ViewData.Model.SomeProperty %> sintaxis para acceder a sus datos y mostrarlos en las ubicaciones deseadas. En cuanto a viewstate, mi recomendación es olvidar que incluso existe.

Recuerde que una de las ventajas de usar MVC es que tiene control sobre el HTML que envía al cliente. Abraza ese poder e intenta encontrar soluciones que te permitan mantener ese control. Los controles de formularios web intentan ocultar el html y, como tal, hacen que sea más difícil personalizar el html cuando sea necesario.

Recomiendo encarecidamente JQuery o una de las otras bibliotecas de JavaScript igualmente potentes. Pero aprenda a usarlos para acceder al DOM HTML directamente y evitar los problemas de identificación de los controles de formularios web.

Puede usar jquery para conectarse a la selección desplegable del lado del cliente y enviar solicitudes de estilo estándar o ajax. Esas solicitudes pueden devolver nuevas páginas, redireccionamientos, fragmentos html o incluso datos JSON que pueden usarse para actualizar la página existente.

La sesión asp.net se puede usar según sea necesario.