En este material le presentaremos algo llamado MVC. Hablemos sobre qué es MVC, toquemos la historia de su creación, comprendamos las ideas y conceptos principales inherentes a MVC, consideremos paso a paso cómo dividir una aplicación en módulos Modelo, Vista, Controlador y también escribamos una pequeña aplicación web en Spring-Boot y usando Spring-MVC como ejemplo, veamos cómo se transfieren los datos del código Java a las páginas html. Para comprender este material, es necesario estar familiarizado con los patrones de diseño, especialmente Observer y Facade. Familiarícese con las solicitudes y respuestas HTTP, comprenda los conceptos básicos de HTML y sepa qué son las anotaciones en Java. Siéntate, prepara té, prepara postre, ensalada, plato principal y primer plato. Empezamos.
Historia de MVC
Las ideas para MVC fueron formuladas por Trygve Reenskaug mientras trabajaba en Xerox PARC a finales de los años 70. En aquellos días, era imposible trabajar con una computadora sin un título académico y el estudio constante de una voluminosa documentación. El problema que Reenskaug resolvió junto con un grupo de desarrolladores muy fuertes fue simplificar la interacción del usuario medio con una computadora. Era necesario crear herramientas que, por un lado, fueran sumamente simples y comprensibles y, por otro, permitieran administrar una computadora y aplicaciones complejas. Reenskaug trabajó en el equipo que desarrolló la computadora portátil "para niños de todas las edades": Dynabook, así como el lenguaje SmallTalk bajo la dirección de Alan Kay. Fue entonces cuando se establecieron los conceptos de una interfaz amigable. El trabajo de Reenskaug con su equipo influyó enormemente en el desarrollo del campo de las TI. Presentemos un hecho interesante que no se relaciona directamente con MVC, pero que ilustra la importancia de esos desarrollos. En 2007, después de la presentación del iPhone de Apple, Alan Kay dijo: “Cuando salió el Macintosh, Newsweek me preguntó qué pensaba de él. Dije: esta es la primera computadora personal digna de crítica. Después de la presentación, Steve Jobs se acercó y preguntó: ¿es el iPhone digno de crítica? Y dije: hazlo de cinco por veinte centímetros y conquistarás el mundo”. Tres años después, el 27 de enero de 2010, Apple presentó el iPad de 9,7 pulgadas. Es decir, Steve Jobs siguió el consejo de Alan Kay casi literalmente. El proyecto en el que trabajó Rennskaug duró 10 años. Y la primera publicación sobre MVC de sus creadores se publicó 10 años después. Martin Fowler, autor de varios libros y artículos sobre arquitectura de software, menciona que aprendió MVC a partir de una versión funcional de SmallTalk. Dado que durante mucho tiempo no hubo información sobre MVC de la fuente principal, así como por varias otras razones, han aparecido una gran cantidad de interpretaciones diferentes de este concepto. Como resultado, muchas personas consideran que MVC es un esquema o patrón de diseño. Con menos frecuencia, MVC se denomina patrón compuesto o una combinación de varios patrones que funcionan juntos para implementar aplicaciones complejas. Pero, de hecho, como se dijo anteriormente, MVC es principalmente un conjunto de ideas/principios/enfoques arquitectónicos que se pueden implementar de varias maneras usando varios patrones... A continuación, intentaremos observar las ideas principales incluidas en el concepto MVC.
Qué es MVC: ideas y principios básicos
VC es un conjunto de ideas y principios arquitectónicos para construir sistemas de información complejos con una interfaz de usuario;
MVC es un acrónimo de Model-View-Controller.
Descargo de responsabilidad: MVC no es un patrón de diseño. MVC es precisamente un conjunto de ideas y principios arquitectónicos para construir sistemas complejos con una interfaz de usuario. Pero por conveniencia, para no repetir cada vez: “Un conjunto de ideas arquitectónicas…”, llamaremos patrón MVC. Comencemos con algo simple. ¿Qué se esconde detrás de las palabras Modelo-Vista-Controlador? Al desarrollar sistemas con una interfaz de usuario, siguiendo el patrón MVC, es necesario dividir el sistema en tres componentes. Estos, a su vez, pueden denominarse módulos o componentes. Di lo que quieras, pero divide entre tres. Cada componente tendrá su propio propósito. Modelo. El primer componente/módulo es el llamado modelo. Contiene toda la lógica empresarial de la aplicación. Vista. La segunda parte del sistema es la vista. Este módulo es responsable de mostrar datos al usuario. Todo lo que ve el usuario es generado por la vista. Controlador. El tercer eslabón de esta cadena es el responsable del tratamiento. Almacena código que es responsable de procesar las acciones del usuario (cualquier acción del usuario en el sistema se procesa en el controlador). El modelo es la parte más independiente del sistema. Tan independiente que no debería saber nada sobre los módulos Vista y Controlador. El modelo es tan independiente que sus desarrolladores pueden no saber prácticamente nada sobre la Vista y el Controlador. El objetivo principal de la Vista es proporcionar información del Modelo en un formato fácil de usar. La principal limitación de la Vista es que no debe cambiar el modelo de ninguna manera. El objetivo principal del Controlador es procesar las acciones del usuario. Es a través del Controlador que el usuario realiza cambios en el modelo. Más precisamente, en los datos que se almacenan en el modelo. Retomemos el diagrama que ya les mostramos en la conferencia: De todo esto podemos sacar una conclusión completamente lógica. Un sistema complejo debe dividirse en módulos. Describamos brevemente los pasos para lograr dicha separación.
Paso 1: separar la lógica empresarial de la aplicación de la interfaz de usuario
La idea clave de MVC es que cualquier aplicación con una interfaz de usuario, como primera aproximación, se puede dividir en 2 módulos: un módulo responsable de implementar la lógica de negocio de la aplicación y una interfaz de usuario. El primer módulo implementará la funcionalidad principal de la aplicación. Este módulo será el núcleo del sistema, en el que se implementa el modelo de dominio de aplicación. En el concepto MVC, este módulo será nuestra letra M, es decir modelo. El segundo módulo implementará toda la interfaz de usuario, incluida la visualización de datos al usuario y la lógica de interacción del usuario con la aplicación. El objetivo principal de esta separación es garantizar que el núcleo del sistema (modelo en terminología MVC) pueda desarrollarse y probarse de forma independiente. La arquitectura de la aplicación después de dicha división se verá así:
Paso 2. Usando el patrón Observer, logre una independencia aún mayor del modelo, así como la sincronización de las interfaces de usuario.
Aquí perseguimos 2 objetivos:
Lograr una independencia aún mayor del modelo.
Sincronizar interfaces de usuario.
El siguiente ejemplo le ayudará a comprender lo que se entiende por sincronización de interfaces de usuario. Digamos que compramos una entrada de cine online y vemos el número de asientos disponibles en la sala. Alguien más puede comprar una entrada de cine al mismo tiempo que nosotros. Si este alguien compra una entrada antes que nosotros, nos gustaría ver que el número de asientos disponibles para nuestra sesión ha disminuido. Ahora pensemos en cómo se puede implementar esto dentro del programa. Supongamos que tenemos un núcleo de sistema (nuestro modelo) y una interfaz (la página web en la que realizamos una compra). En el sitio, 2 usuarios seleccionan simultáneamente un asiento. El primer usuario compró un billete. El segundo usuario debe mostrar esta información en la página. ¿Cómo debería suceder esto? Si actualizamos la interfaz desde el kernel del sistema, nuestro kernel, nuestro modelo, dependerá de la interfaz. Al desarrollar y probar un modelo, deberá tener en cuenta varias formas de actualizar la interfaz. Para lograr esto, debe implementar el patrón Observer. Con su ayuda, el modelo envía notificaciones sobre cambios a todos los suscriptores. La interfaz, al ser tal suscriptora, recibirá una notificación y actualización. El patrón Observer permite que el modelo, por un lado, informe a la interfaz (vista y controlador) que se han producido cambios en ella y, por otro lado, "no sepa" nada sobre ellos y, por lo tanto, permanezca independiente. Por otro lado, esto permitirá sincronizar las interfaces de usuario.
Paso 3. Dividir la interfaz en Vista y Controlador
Seguimos dividiendo la aplicación en módulos, pero en un nivel inferior de jerarquía. En este paso, la interfaz de usuario (que se separó en un módulo separado en el paso 1) se divide en una vista y un controlador. Es difícil trazar una línea estricta entre una vista y un controlador. Si decimos que la vista es lo que ve el usuario y el controlador es el mecanismo a través del cual el usuario puede interactuar con el sistema, existe cierta contradicción. Los controles, como los botones de una página web o un teclado virtual en la pantalla de un teléfono, son esencialmente parte de un controlador. Pero son tan visibles para el usuario como cualquier parte de la vista. Aquí estamos hablando más de división funcional. La tarea principal de la interfaz de usuario es garantizar la interacción del usuario con el sistema. Esto significa que la interfaz tiene sólo 2 funciones:
mostrar y mostrar convenientemente información sobre el sistema al usuario;
ingresar datos de usuario y comandos en el sistema (transmitirlos al sistema);
Estas funciones determinan cómo se debe dividir la interfaz en módulos. Como resultado, la arquitectura del sistema se ve así: Entonces, tenemos una aplicación de tres módulos llamados Modelo, Vista y Controlador. Para resumir:
Siguiendo los principios de MVC, el sistema debe dividirse en módulos.
El módulo más importante e independiente debería ser el modelo.
El modelo es el núcleo del sistema. Necesita la capacidad de desarrollarlo y probarlo independientemente de la interfaz.
Para hacer esto, en el primer paso de la segregación del sistema, debe dividirlo en un modelo y una interfaz.
A continuación, utilizando el patrón Observer, fortalecemos el modelo en su independencia y obtenemos la sincronización de las interfaces de usuario.
El tercer paso es dividir la interfaz en un controlador y una vista.
Todo lo que se requiere para ingresar información del usuario en el sistema es en el controlador.
Todo lo que envía información desde el sistema al usuario está a la vista.
Queda una cosa más importante por discutir y puedes beber cacao.
Un poco sobre la relación entre la Vista y el Controlador y el Modelo
Cuando el usuario ingresa información a través del controlador, realiza cambios en el modelo. Al menos el usuario realiza cambios en los datos del modelo. Cuando el usuario recibe información a través de elementos de la interfaz (a través de la Vista), el usuario recibe información sobre los datos del modelo. ¿Como sucedió esto? ¿Cómo interactúan la Vista y el Controlador con el modelo? Después de todo, no puede ser que las clases de Vista utilicen directamente los métodos de las clases de Modelo para leer/escribir datos; de lo contrario, no puede haber ninguna cuestión de independencia del Modelo. El Modelo representa un conjunto de clases estrechamente interconectadas al que, en el buen sentido, ni la Vista ni el Controlador deberían tener acceso. Para conectar el Modelo con la Vista y el Controlador, es necesario implementar el patrón de diseño Fachada. La fachada del modelo será la capa entre el Modelo y la interfaz, a través de la cual la Vista recibe datos en un formato conveniente y el Controlador cambia los datos llamando a los métodos de fachada necesarios. Esquemáticamente, al final, todo quedará así:
MVC: ¿cuál es el beneficio?
El objetivo principal de seguir los principios de MVC es separar la implementación de la lógica de negocios (modelo) de la aplicación de su visualización (vista). Esta separación aumentará la reutilización del código. Los beneficios de utilizar MVC son más obvios en los casos en que el usuario necesita proporcionar los mismos datos en diferentes formas. Por ejemplo, en forma de tabla, gráfico o cuadro (usando diferentes tipos). Al mismo tiempo, sin afectar la implementación de las vistas, puede cambiar las reacciones a las acciones del usuario (hacer clic en un botón, ingresar datos). Si sigue los principios de MVC, puede simplificar la escritura de programas, aumentar la legibilidad del código y facilitar la expansión y el mantenimiento del sistema en el futuro. En el material final de la serie "Introducción al desarrollo empresarial", veremos la implementación de MVC utilizando Spring-MVC como ejemplo. Parte 8. Escribir una pequeña aplicación en Spring-boot
De todo esto podemos sacar una conclusión completamente lógica. Un sistema complejo debe dividirse en módulos. Describamos brevemente los pasos para lograr dicha separación.
Entonces, tenemos una aplicación de tres módulos llamados Modelo, Vista y Controlador. Para resumir:
GO TO FULL VERSION