Parte 7. Introducción al patrón MVC (Modelo-Vista-Controlador)

Este material forma parte de la serie "Introducción al desarrollo empresarial". Artículos anteriores:

• acerca de la creación de redes
• sobre arquitectura de software
• sobre HTTP/HTTPS
• sobre los conceptos básicos de Maven
• sobre servlets (escribir una aplicación web simple)
• sobre contenedores de servlets

En este artículo conoceremos algo llamado MVC. Hablaremos sobre qué es MVC, tocaremos su historia, exploraremos las ideas y los conceptos básicos incorporados en MVC, veremos paso a paso cómo dividir una aplicación en módulos Modelo, Vista y Controlador, escribiremos un pequeña aplicación web usando Spring Boot y, usando Spring MVC como ejemplo, vea cómo se envían los datos desde el código Java a las páginas HTML. Para comprender este material, debe estar familiarizado con los patrones de diseño, especialmente el observador y la fachada. Y familiarícese con las solicitudes y respuestas HTTP, comprenda los conceptos básicos de HTML y sepa qué son las anotaciones de Java. Tome una taza de café y un refrigerio, y póngase cómodo. Vamos a empezar.

Historia de MVC

Trygve Reenskaug formuló las ideas detrás de MVC mientras trabajaba en Xerox PARC a fines de la década de 1970. En aquellos días, trabajar con computadoras requería un grado y estudio constante de documentación voluminosa. La tarea resuelta por Reenskaug junto con un grupo de desarrolladores muy fuertes fue simplificar la interacción de un usuario común con la computadora. Era necesario crear herramientas que, por un lado, fueran extremadamente simples y comprensibles y, por otro lado, permitieran controlar computadoras y aplicaciones complejas. Reenskaug trabajó en un equipo que desarrolló una computadora portátil "para niños de todas las edades": el Dynabook, así como el lenguaje SmallTalk bajo la dirección de Alan Kay. Fue entonces cuando se establecieron los conceptos de una interfaz amigable. En muchos aspectos, el trabajo realizado por Reenskaug y su equipo influyó en la evolución de la esfera de TI. Aquí hay un hecho interesante que no se aplica directamente a MVC, pero ilustra la importancia de estos desarrollos. alan kaydicho, "Cuando llegué por primera vez a Apple, que fue en el '84, la Mac ya estaba disponible y Newsweek me contactó y me preguntó qué pensaba de la Mac. Dije: 'Bueno, la Mac es la primera computadora personal lo suficientemente buena como para ser criticado.' Entonces, después de anunciar el iPhone en 2007, me lo acercó y me lo entregó. Me dijo: 'Alan, ¿es esto lo suficientemente bueno como para ser criticado?' Y le dije: 'Steve, hazlo del tamaño de una tableta y gobernarás el mundo'". Después de 3 años, el 27 de enero de 2010, Apple presentó el iPad con una diagonal de 9,7 pulgadas. En otras palabras, Steve Jobs siguió casi exactamente el consejo de Alan Kay. El proyecto de Reenskaug duró 10 años. Pero la primera publicación sobre MVC salió a la luz después de otros 10 años. Martin Fowler, autor de varios libros y artículos sobre arquitectura de software, menciona que estudió MVC usando una versión funcional de Smalltalk. Debido a que no hubo información sobre MVC de la fuente original durante mucho tiempo, y por varias otras razones, apareció una gran cantidad de interpretaciones diferentes de este concepto. Como resultado, muchos consideran que MVC es un 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 crear aplicaciones complejas. Pero, como se mencionó anteriormente, MVC es en realidad principalmente un conjunto de ideas/principios/enfoques arquitectónicos que se pueden implementar de varias maneras usando diferentes patrones... A continuación, consideraremos las ideas principales integradas en el concepto de MVC. y por varias otras razones, apareció una gran cantidad de interpretaciones diferentes de este concepto. Como resultado, muchos consideran que MVC es un 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 crear aplicaciones complejas. Pero, como se mencionó anteriormente, MVC es en realidad principalmente un conjunto de ideas/principios/enfoques arquitectónicos que se pueden implementar de varias maneras usando diferentes patrones... A continuación, consideraremos las ideas principales integradas en el concepto de MVC. y por varias otras razones, apareció una gran cantidad de interpretaciones diferentes de este concepto. Como resultado, muchos consideran que MVC es un 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 crear aplicaciones complejas. Pero, como se mencionó anteriormente, MVC es en realidad principalmente un conjunto de ideas/principios/enfoques arquitectónicos que se pueden implementar de varias maneras usando diferentes patrones... A continuación, consideraremos las ideas principales integradas en el concepto de MVC.

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 una abreviatura que significa: Modelo-Vista-Controlador

Descargo de responsabilidad: MVC no es un patrón de diseño. MVC es un conjunto de ideas y principios arquitectónicos para construir sistemas complejos con una interfaz de usuario. Pero por conveniencia, para no decir repetidamente "un conjunto de ideas arquitectónicas...", nos referiremos al patrón MVC. Comencemos con lo simple. ¿Qué se esconde detrás de las palabras Modelo-Vista-Controlador? Cuando utilice el patrón MVC para desarrollar sistemas con una interfaz de usuario, debe dividir el sistema en tres componentes. También se les puede llamar módulos o componentes. Llámelos como quiera, pero divida el sistema en tres componentes. Cada componente tiene su propio propósito. Modelo. El primer componente/módulo se denomina modelo. Contiene toda la lógica de negocio de la aplicación. Vista.La segunda parte del sistema es la vista. Este módulo se encarga de mostrar los datos al usuario. Todo lo que el usuario ve es generado por la vista. Controlador.El tercer eslabón de esta cadena es el controlador. Contiene el código que es responsable de manejar las acciones del usuario (todas las acciones del usuario se manejan en el controlador). El modelo es la parte más independiente del sistema. Tan independiente que no debe saber nada sobre los módulos de vista y controlador. El modelo es tan independiente que sus desarrolladores pueden no saber prácticamente nada acerca de la vista y el controlador. El objetivo principal de la vista es proporcionar información del modelo en un formato que el usuario pueda consumir. La principal limitación de la vista es que no debe cambiar el modelo de ninguna manera. El propósito principal del controlador es manejar las acciones del usuario. Es a través del controlador que el usuario realiza cambios en el modelo. O más precisamente, a los datos que se almacenan en el modelo. Este es el diagrama que viste anteriormente en la lección: De todo esto, podemos sacar una conclusión lógica. Un sistema complejo necesita ser dividido en módulos. Describamos brevemente los pasos para lograr esta separación.

Paso 1. Separe la lógica comercial de la aplicación de la interfaz de usuario

La idea principal de MVC es que cualquier aplicación con una interfaz de usuario se puede dividir en 2 módulos: un módulo responsable de implementar la lógica de negocios y la interfaz de usuario. El primer módulo implementará la funcionalidad principal de la aplicación. Este módulo es el núcleo del sistema, donde se implementa el modelo de dominio de la aplicación. En el paradigma MVC, este módulo es la letra M, es decir, el modelo. El segundo módulo implementa toda la interfaz de usuario, incluida la lógica para mostrar datos al usuario y manejar la interacción del usuario con la aplicación. El objetivo principal de esta separación es garantizar que el núcleo del sistema (el "modelo" en la terminología MVC) se pueda desarrollar y probar de forma independiente. Después de hacer esta separación, la arquitectura de la aplicación queda así:

Paso 2 Use el patrón de observador para hacer que el modelo sea aún más independiente y para sincronizar las interfaces de usuario

Aquí tenemos 2 objetivos:

1. Consiga una independencia aún mayor para el modelo
2. Sincronizar interfaces de usuario

El siguiente ejemplo lo ayudará a comprender lo que queremos decir con sincronización de interfaces de usuario. Supongamos que estamos comprando un boleto de cine en línea y vemos el número de asientos disponibles en el cine. Al mismo tiempo, alguien más puede estar comprando una entrada para el cine. Si esta otra persona compra un boleto antes que nosotros, nos gustaría ver una disminución en la cantidad de asientos disponibles para el horario que estamos considerando. Ahora pensemos en cómo se puede implementar esto dentro de un programa. Supongamos que tenemos el núcleo de nuestro sistema (nuestro modelo) y la interfaz (la página web para comprar boletos). Dos usuarios intentan elegir un asiento en el teatro simultáneamente. El primer usuario compra un boleto. La página web debe mostrar al segundo usuario que esto ha sucedido. ¿Cómo se supone que sucederá esto? Si actualizamos la interfaz desde el núcleo, entonces el núcleo (nuestro modelo) dependerá de la interfaz. A medida que desarrollamos y probamos el modelo, tendremos que tener en cuenta las diversas formas de actualizar la interfaz. Para lograr esto, necesitamos implementar el patrón del observador. Este patrón permite que el modelo envíe notificaciones de cambio a todos los oyentes. Como detector de eventos (u observador), la interfaz de usuario recibe notificaciones y se actualiza. Por un lado, el patrón del observador permite que el modelo informe a la interfaz (vista y controlador) que se han producido cambios sin saber nada al respecto, manteniéndose así independiente. Por otro lado, permite sincronizar las interfaces de usuario. necesitamos implementar el patrón del observador. Este patrón permite que el modelo envíe notificaciones de cambio a todos los oyentes. Como detector de eventos (u observador), la interfaz de usuario recibe notificaciones y se actualiza. Por un lado, el patrón del observador permite que el modelo informe a la interfaz (vista y controlador) que se han producido cambios sin saber nada al respecto, manteniéndose así independiente. Por otro lado, permite sincronizar las interfaces de usuario. necesitamos implementar el patrón del observador. Este patrón permite que el modelo envíe notificaciones de cambio a todos los oyentes. Como detector de eventos (u observador), la interfaz de usuario recibe notificaciones y se actualiza. Por un lado, el patrón del observador permite que el modelo informe a la interfaz (vista y controlador) que se han producido cambios sin saber nada al respecto, manteniéndose así independiente. Por otro lado, permite sincronizar las interfaces de usuario.

Paso 3 Separe la interfaz en vista y controlador

Seguimos dividiendo la aplicación en módulos, pero ahora en un nivel inferior en la jerarquía. En este paso, la interfaz de usuario (que separamos en un módulo distinto en el paso 1) se divide en una vista y un controlador. Dibujar una línea estricta entre la vista y el controlador es difícil. Si decimos que la vista es lo que ve el usuario, y el controlador es el mecanismo que le permite al usuario interactuar con el sistema, podría señalar una contradicción. Los elementos de control, como los botones en una página web o un teclado virtual en la pantalla de un teléfono, son básicamente parte del controlador. Pero son tan visibles para el usuario como cualquier parte de la vista. De lo que realmente estamos hablando aquí es de separación funcional. La principal tarea de la interfaz de usuario es facilitar la interacción del usuario con el sistema.

• salida y visualización conveniente de la información del sistema al usuario
• introducir datos de usuario y comandos (comunicarlos al sistema)

Estas funciones determinan cómo se debe dividir la interfaz de usuario en módulos. Al final, la arquitectura del sistema se ve así: Y así es como llegamos a una aplicación que consta de tres módulos llamados modelo, vista y controlador. Resumamos:

1. De acuerdo con los principios del paradigma MVC, un sistema debe dividirse en módulos.
2. El módulo más importante e independiente debe ser el modelo.
3. El modelo es el núcleo del sistema. Debería ser posible desarrollarlo y probarlo independientemente de la interfaz de usuario.
4. Para lograr esto, en el primer paso de la división, necesitamos dividir el sistema en un modelo y una interfaz de usuario.
5. Luego, utilizando el patrón del observador, reforzamos la independencia del modelo y sincronizamos las interfaces de usuario.
6. El tercer paso es dividir la interfaz de usuario en un controlador y una vista.
7. Todo lo que se requiere para recibir datos de usuario en el sistema está en el controlador.
8. Todo lo que se requiere para entregar información al usuario está en la vista.

Solo una cosa más importante para discutir antes de que pueda beber su chocolate caliente.

Un poco sobre cómo la vista y el controlador interactúan con el modelo

Al ingresar información a través del controlador, el usuario cambia el modelo. O al menos, el usuario cambia los datos del modelo. Cuando el usuario recibe información a través de los elementos de la interfaz (a través de la vista), el usuario está recibiendo información sobre el modelo. ¿Como sucedió esto? ¿Por qué medios la vista y el controlador interactúan con el modelo? Después de todo, las clases de la vista no pueden llamar directamente a los métodos de las clases del modelo para leer/escribir datos. De lo contrario, no podríamos decir que el modelo es independiente. El modelo es un conjunto de clases estrechamente relacionadas a las que ni la vista ni el controlador deberían tener acceso. Para conectar el modelo a la vista y al controlador, necesitamos implementar el patrón de diseño de fachada. La fachada del modelo es la capa entre el modelo y la interfaz de usuario, a través del cual la vista recibe datos formateados convenientemente, y el controlador cambia los datos llamando a los métodos necesarios en la fachada. Al final, todo queda así:

MVC: ¿Qué ganamos?

El principal objetivo del paradigma MVC es separar la implementación de la lógica empresarial (el modelo) de su visualización (la vista). Esta separación aumenta las posibilidades de reutilización del código. Los beneficios de MVC son más evidentes cuando necesitamos presentar los mismos datos en diferentes formatos. Por ejemplo, como tabla, gráfico o gráfico (usando diferentes vistas). Al mismo tiempo, sin afectar la forma en que se implementan las vistas, podemos cambiar la forma en que respondemos a las acciones del usuario (clics de botones, entrada de datos). Si sigue los principios de MVC, puede simplificar el desarrollo de software, aumentar la legibilidad del código y mejorar la extensibilidad y el mantenimiento. En el artículo final de la serie "Introducción al desarrollo empresarial", veremos una implementación de MVC creada con Spring MVC. Parte 8. Escribamos una pequeña aplicación usando Spring Boot