Webform y MVC, por qué MVC es mejor
Si observa la agenda reciente de Microsoft, encontrará que su enfoque actual no está solo en MVC, sino también en MVC. La pregunta es ¿por qué Microsoft está tan interesado en abandonar el formulario web APS.NET tradicional y pasar a ASP.NET MVC? Este artículo analiza principalmente este tema.
Código de fondo de ASP.NET Webform (detrás del código): bendición y maldición
Si ha prestado mucha atención a la tecnología ASP.NET Webform, encontrará que está más cerca de lo visual. diseño En otras palabras, los desarrolladores solo necesitan arrastrar y soltar controles desde el panel de diseño para completar la interfaz de usuario y luego implementar el código lógico en el código subyacente para completar la función final de la página web.
En otras palabras, cuando arrastras un botón desde el panel de diseño, se generará un objeto de botón en el código de fondo. Solo necesitas implementar el código de respuesta del evento en el evento de clic del botón. .
Clase parcial pública WebForm1: System.Web.UI.Page
{
Page_Load vacío protegido (remitente del objeto, EventArgs e)
{
// Los desarrolladores escriben el código aquí
}
Protected void Button1_Click(remitente del objeto, EventArgs e)
{
// Los desarrolladores escriben el código aquí
}
}
Cuando arrastramos algunos elementos de la interfaz de usuario a la página, hacemos doble clic en Generar un serie de códigos de respuesta de eventos en el código de fondo, y estos códigos lógicos están en el archivo ASPX.CS.
Este archivo de código backend es la clave para ASP.NET Webform. Puede aplicar todas las características de .NET en este archivo, incluidos eventos, delegación, protocolo HTTP, sesión, etc.
Sin embargo, este modelo detrás del código tiene 5 problemas. A continuación, describiremos estos 5 problemas uno por uno y usaremos ideas de diseño MVC para resolverlos respectivamente.
Pregunta 1: Solución basada en vistas para resolver necesidades basadas en el comportamiento
Nuestro sitio web es, en última instancia, utilizado por los usuarios. Los usuarios deben tener propósitos específicos para visitar el sitio web. El propósito es lograr el propósito deseado a través del comportamiento interactivo del usuario. Por ejemplo, cuando un usuario visita un sitio web de compras, quizás su comportamiento interactivo sea así:
Comprar productos
Imprimir factura
Estos comportamientos interactivos se realizan a través de botones Implementado mediante clic, clic derecho y URL del navegador. Dado que estas interacciones se basan en el protocolo HTTP, si podemos asignar estos comportamientos interactivos a métodos específicos, toda la arquitectura será mucho más simple.
Pero Microsoft no pudo hacer esto porque quería implementar programación web visual, por lo que finalmente eligieron una solución basada en vistas.
Como se puede ver en la imagen de arriba, todo el proceso de solicitud parece muy extraño:
El usuario inicia una solicitud HTTP, como HTTP POST / GET
El servidor IIS La solicitud se asigna a la vista
La vista llama al ciclo de vida de la página y está controlada por eventos para llamar al método de interacción apropiado
Finalmente, el los resultados de la interacción se muestran al usuario final
Debido a que Microsoft eligió un diseño basado en vistas desde el principio, fue difícil para la arquitectura misma acercarse a una idea de diseño basada en la interacción del usuario. En otras palabras, cuando el usuario realiza una solicitud de "compra", primero visita la página de visualización "Shopping.aspx", y el código lógico de fondo está en "Shopping.aspx.cs" Se devolverán los resultados del cálculo de la página. al usuario durante el ciclo de vida de la página.
Si la idea de utilizar MVC se basa en la interacción del usuario, entonces el proceso de solicitud será el siguiente:
Problema 2: efectos secundarios de una mala arquitectura: acoplamiento estrecho
p>
Cuando elige una arquitectura incorrecta, habrá muchos efectos secundarios que serán difíciles de resolver en el futuro. Este problema ocurre en ASP.NET Webform. Aunque el código de fondo detrás está separado en diferentes archivos, el archivo ASPX.CS y el archivo ASPX están estrechamente vinculados, lo que provocará un alto grado de acoplamiento del sistema y será difícil desacoplarlo. es un gran problema de dolor de cabeza.
En pocas palabras, es difícil para nosotros separar simplemente Customer.aspx.cs y CustomerDetailed.aspx. El código de fondo los ha unido estrechamente y es difícil reutilizarlos. Si podemos pasar la solicitud primero a través de la acción en lugar de la vista, y los datos obtenidos por la acción serán determinados por el controlador qué vista se mostrará, entonces el proceso de solicitud será así:
Por lo tanto, podemos controlar fácilmente y de manera conveniente si el resultado final se muestra en una página móvil o en una página normal, de la siguiente manera:
Índice público de resultados de acción (cadena Tipo de dispositivo)
{
if (viewType == "Mobile")
{
return View("MobileView");
}
else
{
return View("NormalView");
}
}
Pregunta 3: HTML no es el único tipo de devolución
Dado que la vista y el código subyacente están estrechamente vinculados, el tipo de devolución predeterminado es fijo y todos son tipos HTML. Si desea cambiar el tipo, debe configurar el tipo de contenido y llamar al método Response.End.
Si creamos una Acción y el tipo de devolución se especifica en la Acción, el sistema puede generar diferentes tipos de devolución según diferentes condiciones en la misma acción. El código es el siguiente:
Índice público de ActionResult(string viewType)
{
if (viewType == "JSON")
{
devuelve Json(nuevo Cliente(), JsonRequestBehavior.AllowGet);
}
else
{
return View("DisplayCustomer", new Customer());
}
}
Pregunta 4: Combinación flexible de vistas y datos
Webform es una arquitectura de vista primero, por lo que la vista determina los datos mostrados, por lo que la escalabilidad de la vista es muy pobre. Si encuentra estructuras de datos complejas, este método será insuficiente.
Pero si se trata de una arquitectura que prioriza el comportamiento, cuando activamos una acción, la acción puede elegir diferentes modelos de datos y ver estructuras de acuerdo con diferentes solicitudes, como se muestra a continuación:
En MVC, puede seleccionar el mismo modelo de datos en diferentes vistas, como en el siguiente código, los datos de datos del cliente se pueden vincular a la vista Detalle del Cliente o a la vista del Cliente.
Índice público de resultados de acción (cadena ViewName,Cliente datos del cliente)
{
if (ViewName == "Detallado")
{
volver Vista("ClienteDetalle",datos del cliente);
}
else
{
volver Vista( "Cliente",customerdata);
}
}
Esto es muy problemático de implementar en Webform.
Pregunta 5. Trate el código subyacente como una clase normal para pruebas unitarias
El código subyacente es una clase muy grande en Webform y no se puede crear una instancia de ella de manera sencilla. Debes saber que Webform hereda de la clase Page. No se puede crear una instancia de la clase Page directamente porque tiene demasiadas dependencias.
Clase parcial pública WebForm1: System.Web.UI.Page
{
Page_Load vacío protegido (remitente del objeto, EventArgs e)
{
}
public void Button1_Click(remitente del objeto, EventArgs e)
{
Sesión["SomeSession"] = " Is this set";
}
}
¿Por qué desea crear una instancia de la clase Página? Una de las razones es facilitar las pruebas unitarias. Por ejemplo, quiero probar un evento de clic en un botón para verificar si la sesión se configuró correctamente. El código en Webform no parece tan cómodo:
[TestMethod]
public void TestMethod1()
{
WebApplication22. obj = new WebApplication22.WebForm1();
obj.Button1_Click(this, new EventArgs());
}
Y se lanzará cuando se ejecute Se produce una excepción:
En MVC, esta clase se convierte en una clase normal. Podemos crear una instancia de ella en el proyecto de prueba y realizar pruebas unitarias en la clase.
clase pública HomeController: Controlador // ? esta clase es simple
{
Índice público ActionResult()
{
Sesión["SomeSession"] = "¿Está configurado esto?";
return View("SomeView");
}
}
Entonces, ¿debería elegir la solución MVC?
Para cambiar de la arquitectura Webform a la arquitectura MVC, debe hacer lo siguiente:
Transferir el código subyacente a la clase del controlador y convertir el método original en acción. método.
La capa intermedia se reemplaza por el modelo de datos y la interfaz lógica.
La vista Ver solo se utiliza para mostrar datos y diseño de página.
La capa DAL no tiene cambios con respecto a otras capas porque tiene poco que ver con el código subyacente.
Entonces, en la arquitectura MVC, las solicitudes de los usuarios se dividen en los siguientes tres pasos:
El usuario final envía una solicitud y el enrutador enruta la solicitud al Controlador apropiado. una entidad lógica y una colección de acciones.
El controlador asigna solicitudes a acciones específicas.
La acción tiene dos tareas. La primera es obtener los datos apropiados y la segunda es vincular estos datos a la vista. La acción crea un modelo de datos, conecta el modelo de datos a la vista especificada y genera los resultados finales correspondientes.