Introducción a la arquitectura MVC
La arquitectura de aplicación más popular que todo programador conoce es MVC . MVC significa Modelo-Vista-Controlador .
No se trata tanto de la arquitectura de las aplicaciones como de la arquitectura de los componentes de las aplicaciones, pero volveremos a este matiz más adelante. ¿Qué es MVC?
MVC es un esquema para separar los datos de la aplicación y la lógica de control en tres componentes separados: modelo, vista y controlador , de modo que cada componente se pueda modificar de forma independiente.
- Model (Modelo) proporciona datos y responde a los comandos del controlador cambiando su estado.
- La Vista es responsable de mostrar los datos del modelo al usuario en respuesta a los cambios del modelo.
- El Controlador (Controller) interpreta las acciones del usuario, notificando al modelo de la necesidad de cambios.
Este modelo fue inventado en 1978 (!) Año. Sí, los problemas con la arquitectura de software adecuada eran relevantes hace 50 años. Así es como este modelo se describe en el diagrama en el original:
El modelo proporciona datos y métodos para trabajar con ellos: consultas a la base de datos, verificación de la corrección. El modelo es independiente de la vista (no sabe cómo representar datos) y del controlador (no tiene puntos de interacción con el usuario), lo que proporciona acceso y gestión de datos.
El modelo está construido de tal manera que responde a las solicitudes cambiando su estado, y se puede incorporar la notificación de "observadores". El modelo, debido a la independencia de la representación visual, puede tener varias representaciones diferentes para un “modelo”.
La vista es responsable de obtener los datos requeridos del modelo y enviarlos al usuario. La vista no procesa la entrada del usuario.
El controlador proporciona la "comunicación" entre el usuario y el sistema. Controla y dirige los datos del usuario al sistema y viceversa. Utiliza un modelo y una vista para implementar la acción deseada.
Existe cierta dificultad con el hecho de que este modelo ha evolucionado un poco a lo largo de las décadas. Es decir, el nombre siguió siendo el mismo, pero el propósito de las partes comenzó a cambiar.
Arquitectura MVC en la web
La idea detrás del patrón de diseño MVC es muy simple: necesitamos separar claramente la responsabilidad de los diferentes comportamientos en nuestras aplicaciones:
Modelo— procesamiento de datos y lógica de aplicación.
vista— proporcionar datos al usuario en cualquier formato admitido.
controlador- procesar las solicitudes de los usuarios y llamar a los recursos apropiados.
La aplicación se divide en tres componentes principales, cada uno de los cuales es responsable de diferentes tareas. Echemos un vistazo más de cerca a los componentes de una aplicación cliente-servidor usando un ejemplo.
Controlador
El usuario hace clic en varios elementos de la página en el navegador, como resultado, el navegador envía varias solicitudes HTTP: GET, POST u otras. El controlador puede incluir el navegador y el código JS que funcionan dentro de la página.
La función principal del controlador en este caso es llamar a métodos en los objetos necesarios, administrar el acceso a los recursos para realizar tareas especificadas por el usuario. Normalmente, el controlador llama al modelo adecuado para la tarea y selecciona la vista adecuada.
Modelo
El modelo en un sentido amplio son los datos y las reglas que se utilizan para trabajar con los datos; juntos forman la lógica comercial de la aplicación. El diseño de una aplicación siempre comienza con la construcción de modelos de los objetos en los que opera.
Digamos que tenemos una tienda en línea que vende libros, entonces, ¿una persona es solo un usuario de la aplicación o también un autor de un libro? Estas preguntas importantes deben abordarse durante el diseño del modelo.
Además, hay conjuntos de reglas: qué se puede hacer, qué no se puede hacer, qué conjuntos de datos son aceptables y cuáles no. ¿Puede existir un libro sin autor? ¿Y el autor sin libros? ¿Puede la fecha de nacimiento del usuario estar en el año 300 y así sucesivamente?
El modelo le da al controlador una vista de los datos que el usuario ha solicitado (mensaje, página del libro, imágenes, etc.). El modelo de datos será el mismo sin importar cómo queramos presentarlo al usuario. Por lo tanto, elegimos cualquier vista disponible para mostrar los datos.
El modelo contiene la parte más importante de nuestra lógica de aplicación , la lógica que resuelve el problema que estamos tratando (foro, tienda, banco, etc.). El controlador contiene principalmente lógica organizativa para la aplicación en sí (al igual que su Administrador de proyectos).
Vista
View proporciona varias formas de representar los datos que se reciben del modelo. Puede ser una plantilla llena de datos. Puede haber varias vistas diferentes y el controlador elige cuál es la mejor para la situación actual.
Una aplicación web generalmente consta de un conjunto de controladores, modelos y vistas. El controlador solo puede estar en el backend, pero también puede haber una variante de varios controladores, cuando su lógica se extiende también por el frontend. Un buen ejemplo de este enfoque es cualquier aplicación móvil.
Ejemplo de MVC en la web
Supongamos que necesita desarrollar una tienda en línea que venda libros. El usuario puede realizar las siguientes acciones: ver libros, registrarse, comprar, agregar artículos al pedido actual, marcar libros que le gustan y comprarlos.
Su aplicación debe tener un modelo que sea responsable de toda la lógica comercial. También necesita un controlador que procese todas las acciones del usuario y las convierta en llamadas de método desde la lógica empresarial. Sin embargo, un método de controlador puede llamar a muchos métodos de modelo diferentes.
También necesita conjuntos de vistas: una lista de libros, información sobre un libro, un carrito de compras, una lista de pedidos. Cada página de una aplicación web es en realidad una vista separada que muestra un aspecto determinado del modelo al usuario.
Veamos qué sucede si un usuario abre una lista de libros recomendados por la librería para ver los títulos. Toda la secuencia de acciones se puede describir en forma de 6 pasos:
Pasos:
- El usuario hace clic en el enlace "recomendado" y el navegador envía una solicitud a, por ejemplo, /libros/recomendaciones.
- El controlador verifica la solicitud : el usuario debe iniciar sesión. O deberíamos tener colecciones de libros para usuarios no registrados. Luego, el controlador llama al modelo y le pide que devuelva la lista de libros recomendados al usuario N.
- El modelo accede a la base de datos, recupera información sobre libros de allí: libros que son populares actualmente, libros comprados por el usuario, libros comprados por sus amigos, libros de su lista de deseos. Con base en estos datos, el modelo crea una lista de 10 libros recomendados y los devuelve al controlador.
- El controlador recibe una lista de libros recomendados y la mira. ¡En esta etapa, el controlador toma decisiones! Si hay pocos libros o la lista está completamente vacía, solicita una lista de libros para un usuario no registrado. Si hay una promoción en curso en este momento, el controlador puede agregar libros promocionales a la lista.
- El controlador determina qué página mostrar al usuario. Puede ser una página de error, una página con una lista de libros, una página de felicitación de que el usuario se ha convertido en el millonésimo visitante.
- El servidor le da al cliente la página ( vista ) seleccionada por el controlador. Se llena con los datos necesarios (nombre de usuario, lista de libros) y va al cliente.
- El cliente recibe la página y se la muestra al usuario.
¿Cuáles son los beneficios de este enfoque?
La ventaja más obvia que obtenemos al usar el concepto MVC es una clara separación de la lógica de presentación (interfaz de usuario) y la lógica de la aplicación (backend).
La segunda ventaja es la división de la parte del servidor en dos: un modelo inteligente ( ejecutor ) y un controlador ( centro de decisiones ).
En el ejemplo anterior, hubo un momento en que el controlador podía recibir una lista vacía de libros recomendados del modelo y decidir qué hacer con ella. Teóricamente, esta lógica se podría poner directamente en el modelo.
Primero, al solicitar libros recomendados, el modelo decidiría qué hacer si la lista está vacía. Luego tendría que agregar el código en el mismo lugar, qué hacer si ahora hay una promoción, luego más opciones diferentes.
Luego resultó que el administrador de la tienda quería ver cómo se vería la página del usuario sin una promoción, o viceversa, no hay promoción ahora, pero quiere ver cómo se mostrará la promoción futura. Y no hay métodos para esto. Por lo tanto, se decidió separar el centro de decisión (controlador) de la lógica de negocios (modelo).
Además de aislar las vistas de la lógica de la aplicación, el concepto MVC reduce en gran medida la complejidad de las aplicaciones grandes. El código está mucho más estructurado, lo que facilita el mantenimiento, la prueba y la reutilización de soluciones.
Al comprender el concepto de MVC, usted, como desarrollador, se da cuenta de dónde necesita agregar ordenando la lista de libros:
- En el nivel de consulta de la base de datos.
- A nivel de lógica de negocio (modelo).
- A nivel de lógica de negocio (controlador).
- En la vista - en el lado del cliente.
Y esta no es una pregunta retórica. En este momento, piense dónde y por qué necesita agregar el código para ordenar la lista de libros.
Modelo MVC clásico
La interacción entre los componentes de MVC se implementa de manera diferente en las aplicaciones web y las aplicaciones móviles. Esto se debe a que la aplicación web es de corta duración, procesa una solicitud de usuario y sale, mientras que la aplicación móvil procesa muchas solicitudes sin reiniciar.
Las aplicaciones web suelen utilizar el modelo "pasivo", mientras que las aplicaciones móviles utilizan el modelo "activo". El modelo activo, a diferencia del pasivo, permite suscribirse y recibir notificaciones de cambios en el mismo. Esto no es necesario para las aplicaciones web.
Así es como se ve la interacción de los componentes en varios modelos:
Las aplicaciones móviles (modelo activo) utilizan eventos y el mecanismo de suscripción de eventos de forma activa. Con este enfoque, view ( view ) se suscribe a los cambios del modelo. Luego, cuando ocurre algún evento (por ejemplo, el usuario hace clic en un botón), se llama al controlador . También le da al modelo un comando para cambiar los datos.
Si algunos datos han cambiado, el modelo genera un evento sobre el cambio de estos datos. Todas las vistas que se han suscrito a este evento (para lo cual es importante cambiar este dato en particular) reciben este evento y actualizan los datos en su interfaz.
En las aplicaciones web, las cosas se organizan de forma un poco diferente. La principal diferencia técnica es que el cliente no puede recibir mensajes del lado del servidor por iniciativa del servidor .
Por lo tanto, un controlador en una aplicación web generalmente no envía ningún mensaje a la vista, pero le da al cliente una nueva página, que técnicamente es una nueva vista o incluso una nueva aplicación cliente (si una página no sabe nada sobre la otra) .
En la actualidad, este problema se resuelve parcialmente utilizando los siguientes enfoques:
- Sondeo regular del servidor en busca de cambios en datos importantes (una vez por minuto o más).
- Los WebSockets permiten que un cliente se suscriba a los mensajes del servidor.
- Notificaciones web push desde el lado del servidor.
- El protocolo HTTP/2 permite que el servidor inicie el envío de mensajes al cliente.