| Modelo-Vista-Controlador | |
|---|---|
| inglés Modelo-Vista-Controlador | |
| Estructura |
|
| Descrito en Patrones de diseño | No |
Model-View-Controller ( MVC , "Model-View-Controller", "Model-View-Controller") 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 la modificación de cada componente se puede realizar de forma independiente [1] .
El concepto de MVC fue descrito por Trygve Reenskaug en 1978 [1] [2] , quien trabajaba en el centro de investigación Xerox PARC en el lenguaje de programación Smalltalk . Más tarde, Steve Burbeck implementó el patrón en Smalltalk-80 [1] [3] [4] .
La versión final del concepto MVC se publicó recién en 1988 en la revista Technology Object [5] .
Posteriormente, el patrón de diseño comenzó a evolucionar. Por ejemplo, se introdujo una versión jerárquica de HMVC ; MVA , MVVM [6] [3] [4] .
Otra ronda de popularidad fue provocada por el desarrollo de marcos de implementación rápida en Python , PHP y Ruby : Django , Laravel y Ruby on Rails, respectivamente. En el momento de 2017, los marcos con MVC han tomado una posición destacada en relación con otros marcos sin este patrón [7] .
Con el desarrollo de la programación orientada a objetos y el concepto de patrones de diseño , se crearon una serie de modificaciones del concepto MVC que, al ser implementadas por diferentes autores, pueden diferir del original. Entonces, por ejemplo, Erian Vermi en 2004 describió un ejemplo de un MVC generalizado [8] .
En el prefacio de la disertación de Richard Pawson " Objetos desnudos ", Trygve Reenskaug menciona su primera versión inédita de MVC, según la cual [9] :
El propósito principal de aplicar este concepto es separar la lógica de negocios ( modelo ) de su visualización ( vista , vista ). Debido a esta separación, aumenta la posibilidad de reutilización de código . Este concepto es más útil cuando el usuario necesita ver los mismos datos al mismo tiempo en diferentes contextos y/o desde diferentes puntos de vista. En particular, se realizan las siguientes tareas:
El concepto MVC le permite separar el modelo, la vista y el controlador en tres componentes separados:
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 los datos) y del controlador (no tiene puntos de interacción con el usuario), solo proporciona acceso y manipulación de los 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 [10] .
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.
Dado que MVC no tiene una implementación estricta, se puede implementar de diferentes maneras. No existe una definición generalmente aceptada de dónde debe ubicarse la lógica empresarial. Puede estar tanto en el controlador como en el modelo. En este último caso, el modelo contendrá todos los objetos comerciales con todos los datos y funciones.
Algunos marcos definen rígidamente dónde se debe colocar la lógica comercial, otros no tienen tales reglas.
Tampoco se especifica dónde se debe ubicar la validación de los datos ingresados por el usuario. Las validaciones simples pueden incluso ocurrir en una vista, pero son más comunes en un controlador o modelo.
La internacionalización y el formato de los datos también carecen de una guía clara sobre la ubicación.
Para implementar el esquema "Modelo-Vista-Controlador", se utiliza una cantidad bastante grande de patrones de diseño (dependiendo de la complejidad de la solución arquitectónica), los principales son " observador ", " estrategia ", " enlazador " [11 ] .
La implementación más típica es en la que se separa la vista del modelo estableciendo un protocolo de interacción entre ambos que utiliza el “aparato de eventos” (designación por “eventos” de determinadas situaciones que se presentan durante la ejecución del programa, y envío de notificaciones sobre a todos aquellos que se suscribieron para recibir): para cada cambio específico en los datos internos del modelo (denotado como un "evento"), notifica a las vistas que dependen de él que están suscritas para recibir dicha notificación, y la vista es actualizado. Así es como se usa el patrón de " observador " .
Al procesar la reacción del usuario, la vista selecciona, en función de la reacción, el controlador deseado , que proporcionará una u otra conexión con el modelo. Para ello, se utiliza el patrón " estrategia ", o puede haber una modificación utilizando en su lugar el patrón " comando " .
Para la posibilidad del mismo tipo de manejo de subobjetos de tipo jerárquico complejo-compuesto, se puede utilizar la plantilla “ linker ” . Además, se pueden usar otros patrones de diseño , por ejemplo, " método de fábrica ", que le permitirá establecer el tipo de controlador predeterminado para la vista correspondiente.
Los programadores principiantes suelen interpretar el modelo arquitectónico MVC como un modelo MVC pasivo: el modelo actúa únicamente como un conjunto de funciones para acceder a los datos y el controlador contiene la lógica comercial . Como resultado, el código del modelo es, de hecho, un medio para obtener datos del DBMS , y el controlador es un módulo típico lleno de lógica comercial. Como resultado de este entendimiento, los desarrolladores de MVC comenzaron a escribir código que Padrigue Brady (conocido en los círculos de la comunidad de Zend Framework ) describió como "TTUK" ("Fat Stupid Ugly Controllers"; Fat Stupid Ugly Controllers):
El TTUK promedio obtenía datos de una base de datos (usando una capa de abstracción de base de datos, fingiendo que era un modelo) o manipulaba, validaba, escribía y pasaba los datos a una Vista. Este enfoque se ha vuelto muy popular porque el uso de tales controladores es similar a la práctica clásica de usar un archivo php separado para cada página de la aplicación.
— [ http://blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated/ La M en MVC: Por qué los modelos son incomprendidos y poco apreciadosPero en la programación orientada a objetos se utiliza el modelo activo [12] MVC, donde el modelo no es solo una combinación de código de acceso a datos y DBMS , sino toda la lógica de negocio ; los modelos también pueden encapsular otros modelos dentro de sí mismos. Los controladores, como elementos de un sistema de información , sólo son responsables de:
Solo en este caso, el controlador se vuelve "delgado" y realiza exclusivamente la función de un enlace (capa adhesiva) entre los componentes individuales del sistema de información .