La diferencia entre mvc y la arquitectura de tres niveles
En primer lugar, MVC y la arquitectura de tres niveles son diferentes.
En la arquitectura de tres niveles, DAL (capa de acceso a datos), BLL (capa de lógica empresarial) y la capa WEB realizan cada una sus propias tareas, cuyo objetivo es separar responsabilidades.
MVC es un controlador de vista de modelo. Estrictamente hablando, estos tres elementos se suman a la capa WEB en la arquitectura de tres niveles. En otras palabras, MVC divide la capa WEB en la arquitectura de tres niveles en tres partes: controlador, vista y entidad. El controlador completa la lógica de la página y se comunica con la capa de interfaz a través de entidades. La capa C habla directamente con el BLL de la tercera capa.
Por lo tanto, no existe el concepto de acción en la estructura de tres capas. neto.
Asp.net MVC es un nuevo marco de desarrollo de sitios web lanzado por Microsoft. Está diseñado para resolver el problema de la inseparabilidad del modelo, la vista y el controlador en el desarrollo tradicional de ASP.NET.
Para resolver los problemas de portabilidad, mantenibilidad y escalabilidad, los sitios web ordinarios diseñarán el sitio web en tres módulos independientes. El modelo es responsable de la parte de la base de datos, la Vista es responsable de la interfaz de la página web y el Controlador es responsable de la interacción entre la interfaz, los datos y la lógica empresarial. Para un sitio web diseñado de esta manera, si desea diseñar o volver a desarrollar un módulo, no tendrá ningún impacto en otros módulos. Sin embargo, el código de fondo de la página de asp.net tiene una correspondencia uno a uno con el código de cada página y, en algunos casos, la lógica empresarial se escribe inevitablemente en el código de fondo asociado con la Vista. De esta manera, no se puede garantizar la separación de vistas y controladores, y es difícil reescribir y actualizar el sitio web.
En MVC, el código de la página no corresponde al código de fondo uno a uno, sino que se almacena en el controlador y la vista, lo que resuelve por completo el problema de que la vista y el controlador no pueden ser independientes. . Mejorando así el proceso de reescritura y actualización del sitio web.
Sin embargo, MVC también tiene sus defectos. Dado que los controles del servidor ya no se pueden usar en el código de la página, el uso de algunos controles del lado del servidor en ASP.NET trae problemas y también trae muchos obstáculos al diseño de la página.
ASP.NET MVC es un nuevo marco de desarrollo de sitios web lanzado por Microsoft en abril de 2009, /en-us/library/dd394709.aspx, que integra las ideas de desarrollo MVC tradicionales en el desarrollo del medio ASP.NET.
Entonces déjame hablar también sobre mi comprensión de los dos.
En primer lugar, hay problemas con esta pregunta en sí. ¿Cuál es la diferencia entre "estructura XX" y "modelo XX"? ¿Cuáles son las diferencias entre el sistema social de China y el estilo de vida estadounidense?
Ambas personas hablan desde diferentes direcciones y ángulos. En aplicaciones prácticas, tienen algunas características similares, que no se explican en profundidad en muchos libros, lo que genera confusión. Para entenderlos mejor, hablemos de sus diferencias.
En primer lugar, la estructura de N capas es una jerarquía de abstracción de software, que es una división vertical de software complejo. Cada nivel completa el mismo tipo de operación, dividiendo así varios tipos de código según las tareas que completan, para reducir la complejidad del software y mejorar su mantenibilidad. En términos generales, las capas son interdependientes. El código de nivel superior no se puede desarrollar antes de que se determine la interfaz (contrato) del código de nivel inferior. Los cambios en la interfaz (contrato) del código de nivel inferior harán que el código de nivel superior cambie al mismo tiempo. La estructura de tres capas es un tipo de estructura de N capas, que es una estructura de N capas ampliamente utilizada después de un uso prolongado. Circula ampliamente e incluso está escrito en libros de texto como una jerarquía de software típica.
El patrón MVC es un patrón de diseño compuesto que se puede utilizar para resolver algunos problemas prácticos en situaciones específicas y se puede practicar repetidamente. Casualmente, también se compone de tres cosas, por lo que la gente tiene una correspondencia natural: capa de visualización-vista; capa de lógica empresarial-control; capa de persistencia-modelo. En primer lugar, no existe una estructura jerárquica obvia entre las tres en MVC. No hay dependencias descendentes obvias. En cambio, las vistas y los modelos tienden a ser independientes y los controles son el puente que los conecta. Se parecen más a divisiones horizontales. De esta manera, cada bloque en MVC se puede probar de forma independiente y, en la estructura de tres niveles, la prueba en ejecución del módulo de nivel superior inevitablemente proporcionará código de nivel inferior o códigos auxiliares que proporcionan la misma interfaz. Relativamente hablando, MVC es mucho más complejo, pero tiene una estructura más clara y un menor acoplamiento.
Además, el interior de cada bloque en MVC, especialmente el interior del modelo, a menudo se diseña en múltiples capas.
En mi opinión, en la estructura de un buen patrón MVC, el control es el núcleo, pequeño y relativamente estable, y puede proporcionar puntos de extensión como marco central, pero básicamente se puede configurar y ejecutar simplemente sin ningún código. Una vista puede ser un conjunto o varios motores de vista opcionales, lo que determina la interfaz presentada por el software. El principal esfuerzo al usarlo radica en los puntos de extensión y el número variable de plantillas de vista según sea necesario. Los modelos son proveedores de servicios que determinan la funcionalidad proporcionada por el software. Su interior puede ser algunas clases ordinarias, o pueden ser clases que implementan algunas interfaces. Puede ser colorido según el servicio. Para software complejo, se puede dividir en muchas capas, como capa de lógica empresarial, capa de proveedor de servicios, capa de proveedor de sistemas, capa de proveedor de datos y capa de acceso a datos.
El ejemplo que uso a menudo para comparar MVC es la consola de juegos de cartucho que jugaba cuando era niño. El control es el anfitrión. En términos generales, sólo necesito comprar un host. Siempre que no sea malo, puede dejarme jugar a este juego en cualquier momento. La vista es de un televisor y una consola de juegos. Este televisor puede funcionar de forma independiente. Ya sea una señal de televisión, una señal de un reproductor de DVD o una señal de una consola de juegos, simplemente se muestra y determina qué tipo de efecto vemos. Si quiero una pantalla más grande o más colorida, sólo necesito comprar el televisor correspondiente. El mango también se puede cambiar, ya sea por control remoto o por vibración. El modelo es un cartucho de juego, lo que determina absolutamente a qué juego juego, ya sea Contra o Super Mario. Los fabricantes de consolas de juegos y televisores nunca saben qué tipo de juegos se pueden ejecutar en él. El cartucho puede contener código de juego y unidades de almacenamiento, que están diseñadas según las necesidades del juego.
Un amigo mencionó la interfaz con ranura para tarjetas que proporciona la consola de juegos. En diseño, a veces un control proporciona un conjunto de interfaces para la implementación de un modelo o vista, formando así una relación de dependencia. En términos generales, este diseño no tiene muchos problemas, pero aumentará el acoplamiento entre módulos y provocará cierta intrusión. Para ser más completo, el contrato no necesita proporcionar una interfaz. El contrato puede proporcionar información de configuración (o información de metadatos) + reflexión. Luego, esta interfaz se puede degenerar para que se ajuste simplemente a CLS, que es una clase normal. Como USB ahora se usa comúnmente como interfaz de computadora, ya sea una unidad flash USB, una impresora, un escáner o un dongle, todos son dispositivos USB comunes.
Mencionar USB está un poco fuera de tema. El diseño de capacidad de conexión del módulo es incluso un diseño intercambiable en caliente. El sistema puede instalar o eliminar módulos dinámicamente sin detener el sistema. El montaje dinámico de módulos requiere que el sistema descubra automáticamente nuevos módulos y configure automáticamente nuevos módulos en función de información de autodescripción. La eliminación puede ser más compleja y requerir una función como Quitar hardware con seguridad.
Al diseñar un marco ampliamente reutilizable, se considerarán muchas situaciones para lograr una mayor adaptabilidad. El patrón MVC se puede aplicar arbitrariamente en proyectos generales.