Cómo diferenciar entre Webform y MVC
La mayor diferencia entre MVC y WebForm
Al usar el marco ASP.NET MVC para crear un proyecto predeterminado, la primera sensación intuitiva es que la dirección se ha reescrito. Después de un pequeño análisis del código fuente y los archivos de configuración, no es difícil ver que MVC usa httpModules para interceptar la dirección solicitada, específicamente usando la biblioteca de clases System.Web.Routing (he olvidado cómo usar MVC2 y MVC1). Esta biblioteca de clases está empaquetada en .NET Framework3.5 SP1, es natural que MVC2 requiera el soporte de SP1. La biblioteca de clases System.Web.Routing proporcionada por SP1 puede resolver fácilmente el problema de la interceptación de solicitudes y la codificación también se maneja bien. La clase UrlRoutingModule necesita interceptar la solicitud. Antes de eso, Application_Start debe proporcionar una configuración de interceptación al objeto global de RouteTable. A continuación, cuando el usuario accede a la página, la clase UrlRoutingModule intercepta la solicitud y ve si RouteTable cumple con las reglas. Si coincide, llamará a MvcHandler. Si la dirección coincide con la regla "*.mvc", se registrará en el nodo de configuración de httpHandlers. El método ProcessRequest de MvcHandler llamará al controlador para ejecutarlo. De hecho, todo el proceso es una caja negra que los usuarios no pueden sentir. Después de ejecutar un método en el controlador, se devuelve el resultado y luego se accede a la página aspx específica.
Al analizar el elemento de trabajo MVC, puede compararlo con WebForm. Sabemos que el modelo empresarial MVC se ejecuta en el controlador y que la página aspx solo es responsable de la visualización. Por lo tanto, la ejecución real del negocio en MVC avanza a HttpMolde, mientras que las solicitudes de WebForm solo se ejecutan en el contenedor httpHandler. En otras palabras, la separación de controladores y vistas en MVC utiliza el aislamiento de canalización de solicitudes de ASP.Net, que sin duda logrará la separación de código de nivel lógico sin afectar la eficiencia (una solicitud y Response.Redirect es la segunda solicitud).
Figura 1 Modelo de trabajo MVC
Obviamente, la ventaja del trabajo MVC es que es más propicio para comprender la lógica en capas y comprender la jerarquía del código. El marco ha aislado el flujo entre el controlador y la página aspx. En cuanto al proceso de llamada entre la página Controlador o Vista y el Modelo, aún debe controlarlo usted mismo. El marco MVC de ASP.NET implementa una gestión separada del código del controlador.
En cuanto al modelo de desarrollo de WebForm, solo se ejecuta en el contenedor HttpHandler y se superpone a él. Carece de soporte en la situación general y solo puede confiar en la separación lógica. No es que no se pueda separar, pero está sujeto a ciertas restricciones. La interceptación de HttpHandler está relacionada con el sufijo de acceso. Cuando se solicita una página, es un controlador, que realiza la visualización y la separación lógica del modelo WebForm y es el controlador de eventos de WinForm. Obviamente, el evento debe estar registrado en la página, como un código como Button1_Click. Antes de ejecutar Button1_Click, primero se debe ejecutar el método Page_Load. El código de visualización se escribe en el método Page_Load, lo que hace que sea necesario escribir código obsoleto adicional, como el juicio if (!Page.IsPostBack). La parte que debe mostrarse después de ejecutar Button1_Click es más difícil de manejar escribiendo otro método que también debe llamarse en Button1_Click. Otra solución es utilizar Response.Redirect, que maneja la lógica en la página aspx y salta a otra página de visualización cuando se completa.
La desventaja de esto es que es difícil disfrutar de los datos en dos páginas y el salto se realiza a través de la etiqueta 302, por lo que hay una solicitud adicional. Server.Execute, Server.Transfer o Context.RewritePath también se pueden procesar de esta manera. La conversión de las dos páginas se completa en el lado del servidor y se puede decir que es similar al procesamiento de datos. La desventaja del método del marco MVC es que debe configurarse manualmente.
Del análisis anterior, podemos ver que el marco MVC tiene grandes ventajas, y WebForm no está exento de ventajas y es más fácil de desarrollar en aplicaciones simples. WebForm también puede implementar el mismo método de capas que MVC, pero necesita escribir más código durante el procesamiento. Y creo que el mayor problema encontrado en el desarrollo en capas de WebForm es el problema de la transmisión de datos entre páginas, y dominar las habilidades de usar aplicaciones de salto del lado del servidor en WebForm (Server.Execute, Server.Transfer o Context.RewritePath) se resuelve. El problema de la transmisión de datos para el desarrollo, y el uso de WebForm no está exento de ventajas. Con respecto a los problemas de transmisión de datos, utilizar el desarrollo WebForm es más fácil de entender que el marco MVC y no produce configuraciones complejas. También es una muy buena opción.