Modelo-vista-controlador ( MVC ) es un patrón de diseño de software [1] comúnmente utilizado para desarrollar interfaces de usuario que divide la lógica del programa relacionado en tres elementos interconectados. Estos elementos son las representaciones internas de la información (el modelo ), la interfaz (la vista ) que presenta información y la acepta del usuario, y el software del controlador que los vincula. [2] [3]
Este patrón , utilizado tradicionalmente para interfaces gráficas de usuario (GUI) de escritorio, se hizo popular para diseñar aplicaciones web . [4] Los lenguajes de programación populares tienen marcos MVC que facilitan la implementación del patrón.
MVC, uno de los conocimientos fundamentales en el desarrollo inicial de las interfaces gráficas de usuario, se convirtió en uno de los primeros enfoques para describir e implementar construcciones de software en términos de sus responsabilidades . [5]
Trygve Reenskaug creó MVC mientras trabajaba en Smalltalk -79 como científico visitante en el Centro de Investigación Xerox Palo Alto (PARC) a finales de los años 1970. [6] [7] [8] : 330 Quería un patrón que pudiera usarse para estructurar cualquier programa donde los usuarios interactúen con un conjunto de datos grande y complicado. Su diseño inicialmente tenía cuatro partes: modelo , vista, cosa y editor. Después de discutirlo con los otros desarrolladores de Smalltalk, él y el resto del grupo se decidieron por el modelo, la vista y el controlador. [6]
En su diseño final, un modelo representa alguna parte del programa de forma pura e intuitiva. Una vista es una representación visual de un modelo, que recupera datos del modelo para mostrarlos al usuario y pasa solicitudes entre el usuario y el modelo. Un controlador es una parte organizativa de la interfaz de usuario que diseña y coordina múltiples Vistas en la pantalla, y que recibe entradas del usuario y envía los mensajes apropiados a sus Vistas subyacentes. Este diseño también incluye un Editor como un tipo de controlador especializado que se utiliza para modificar una vista particular y que se crea a través de esa vista. [6]
Smalltalk-80 admite una versión de MVC que evolucionó a partir de ésta. [6] Proporciona clases abstractas view, controllerasí como varias subclases concretas de cada una que representan diferentes widgets genéricos. En este esquema, a Viewrepresenta alguna forma de mostrar información al usuario y a controllerrepresenta alguna forma para que el usuario interactúe con a view. A viewtambién está acoplado a un objeto modelo, pero la estructura de ese objeto se deja en manos del programador de la aplicación. El entorno Smalltalk-80 también incluye un "MVC Inspector", una herramienta de desarrollo para ver la estructura de un modelo, vista y controlador determinados en paralelo. [9]
En 1988, un artículo en The Journal of Object Technology (JOT) escrito por dos ex empleados de PARC presentó MVC como un "paradigma y metodología de programación" general para los desarrolladores de Smalltalk-80. Sin embargo, su esquema difería tanto del de Reenskaug et al. como del presentado por los libros de referencia Smalltalk-80. Definieron una vista como que cubre cualquier preocupación gráfica, siendo un controlador un objeto más abstracto, generalmente invisible, que recibe entradas del usuario e interactúa con una o varias vistas y solo un modelo. [10]
El patrón MVC evolucionó posteriormente, [11] dando lugar a variantes como modelo-vista-controlador jerárquico (HMVC), modelo-vista-adaptador (MVA), modelo-vista-presentador (MVP), modelo-vista-modelo de vista (MVVM). ), y otros que adaptaron MVC a diferentes contextos.
El uso del patrón MVC en aplicaciones web creció después de la introducción de WebObjects de NeXT en 1996, que fue escrito originalmente en Objective-C (que tomó prestado en gran medida de Smalltalk) y ayudó a hacer cumplir los principios de MVC. Más tarde, el patrón MVC se hizo popular entre los desarrolladores de Java cuando WebObjects se portó a Java . Los marcos posteriores para Java, como Spring (lanzado en octubre de 2002), continuaron el fuerte vínculo entre Java y MVC.
En 2003, Martin Fowler publicó Patterns of Enterprise Application Architecture , que presentaba MVC como un patrón en el que un "controlador de entrada" recibe una solicitud, envía los mensajes apropiados a un objeto modelo, toma una respuesta del objeto modelo y pasa la respuesta a la vista adecuada para su visualización. [8] : 56 Esto se acerca al enfoque adoptado por el marco de aplicaciones web Ruby on Rails (agosto de 2004), en el que el cliente envía solicitudes al servidor a través de una vista en el navegador; estas solicitudes son manejadas por un controlador en el servidor y el controlador se comunica con los objetos del modelo apropiados. [12] El marco Django (julio de 2005, para Python ) presentó una versión similar de "vista de plantilla de modelo" (MTV) del patrón, en la que una vista recupera datos de los modelos y los pasa a las plantillas para su visualización. [13] Tanto Rails como Django debutaron con un fuerte énfasis en el despliegue rápido, lo que aumentó la popularidad de MVC fuera del entorno empresarial tradicional en el que ha sido popular durante mucho tiempo.
El componente central del patrón. Es la estructura de datos dinámica de la aplicación, independiente de la interfaz de usuario. [14] Gestiona directamente los datos, la lógica y las reglas de la aplicación. En Smalltalk-80, el diseño de un tipo de modelo se deja enteramente en manos del programador. [15] Con WebObjects, Rails y Django, un tipo de modelo normalmente representa una tabla en la base de datos de la aplicación . [16] [17] [18]
Cualquier representación de información como un gráfico, diagrama o tabla. Son posibles múltiples vistas de la misma información, como un gráfico de barras para la administración y una vista tabular para los contadores.
En Smalltalk-80, una vista es solo una representación visual de un modelo y no maneja la entrada del usuario. [19] Con WebObjects, una vista representa un elemento completo de la interfaz de usuario, como un menú o un botón, y recibe información del usuario. [20] Sin embargo, tanto en Smalltalk-80 como en WebObjects, las vistas deben ser de uso general y componibles. [21] [22]
Con Rails y Django, el papel de la vista lo desempeñan las plantillas HTML, por lo que en su esquema una vista especifica una interfaz de usuario en el navegador en lugar de representar un widget de interfaz de usuario directamente. [23] [24] (Django opta por llamar a este tipo de objeto "plantilla" a la luz de esto. [25] ) Este enfoque pone relativamente menos énfasis en vistas pequeñas y componibles; una vista típica de Rails tiene una relación uno a uno con una acción del controlador. [26]
Las vistas Smalltalk-80 se comunican tanto con un modelo como con un controlador, [27] mientras que con WebObjects, una vista habla sólo con un controlador, que luego habla con un modelo. [28] Con Rails y Django, un controlador/vista utiliza una vista/plantilla al preparar una respuesta para el cliente. [29] [30]
Acepta entradas y las convierte en comandos para el modelo o vista. [31]
Un controlador Smalltalk-80 maneja eventos de entrada del usuario, como presionar botones o mover el mouse. [32] En cualquier momento dado, cada controlador tiene una vista y un modelo asociados, aunque un objeto modelo puede escuchar desde muchos controladores diferentes. Sólo un controlador, el controlador "activo", recibe la entrada del usuario en un momento dado; un objeto de administrador de ventanas global es responsable de configurar el controlador activo actual. Si la entrada del usuario solicita un cambio en un modelo, el controlador le indicará al modelo que cambie, pero el modelo es entonces responsable de indicarle a sus vistas que se actualicen. [33]
En WebObjects, las vistas manejan la entrada del usuario y el controlador media entre las vistas y los modelos. Puede haber sólo un controlador por aplicación o un controlador por ventana. Gran parte de la lógica específica de la aplicación se encuentra en el controlador. [34]
En Rails, las solicitudes que llegan a la aplicación en el servidor desde el cliente se envían a un "enrutador", que asigna la solicitud a un método específico de un controlador específico. Dentro de ese método, el controlador interactúa con los datos de la solicitud y cualquier objeto del modelo relevante y prepara una respuesta utilizando una vista. Convencionalmente, cada vista tiene un controlador asociado; por ejemplo, si la aplicación tuviera una vista, normalmente también clienttendría un controlador asociado . ClientsSin embargo, los desarrolladores son libres de crear otros tipos de controladores si lo desean. [35]
Django llama al objeto que desempeña este rol una "vista" en lugar de un controlador. [30] Una vista de Django es una función que recibe una solicitud web y devuelve una respuesta web. Puede utilizar plantillas para crear la respuesta. [36]
Además de dividir la aplicación en estos componentes, el diseño modelo-vista-controlador define las interacciones entre ellos. [37]
Al igual que con otros patrones de software, MVC expresa el "núcleo de la solución" a un problema y al mismo tiempo permite adaptarlo a cada sistema. [38] Los diseños particulares de MVC pueden variar significativamente de la descripción tradicional aquí. [39]
Como escribió Alan Kay en 2003, la motivación original detrás del MVC era permitir la creación de una interfaz gráfica para cualquier objeto. [40] Esto se describió en detalle en el libro Naked Objects de Richard Pawson . [40]
Trygve Reenskaug, creador de MVC en PARC, ha escrito que "MVC fue concebido como una solución general al problema de los usuarios que controlan un conjunto de datos grande y complejo". [6]
En su guía de 1991 Inside Smalltalk , los profesores de informática de la Universidad de Carleton, Wilf LaLonde y John Pugh, describieron las ventajas del MVC estilo Smalltalk-80 como:
Aunque originalmente se desarrolló para computadoras de escritorio, MVC ha sido ampliamente adoptado como diseño para aplicaciones World Wide Web en los principales lenguajes de programación . Se han creado varios marcos web que hacen cumplir el patrón. Estos marcos de software varían en sus interpretaciones, principalmente en la forma en que se dividen las responsabilidades de MVC entre el cliente y el servidor . [42] Los primeros marcos MVC adoptaron un enfoque de cliente ligero que colocaba casi todo el modelo, la vista y la lógica del controlador en el servidor. En este enfoque, el cliente envía solicitudes de hipervínculos o envíos de formularios al controlador y luego recibe una página web (u otro documento) completa y actualizada desde la vista; el modelo existe completamente en el servidor. [42] Los marcos posteriores han permitido que los componentes MVC se ejecuten parcialmente en el cliente, utilizando Ajax para sincronizar datos.
Más profundamente, el marco existe para separar la representación de la información de la interacción del usuario.
El modelo puede ser cualquier objeto sin restricción.
En WebObjects, un modelo establece y mantiene una correspondencia entre una clase de objeto empresarial y los datos almacenados en una base de datos relacional.
Esto creará un
modelo, asignado a una tabla de productos en la base de datos.
ProductGeneralmente, cada modelo se asigna a una única tabla de base de datos.
La vista se encarga de proporcionar una representación visual del objeto.
Los objetos de vista representan cosas visibles en la interfaz de usuario (ventanas, por ejemplo, o botones).
[MVC] permite utilizar vistas como piezas para ensamblar en unidades más grandes; Se pueden construir nuevos tipos de vistas utilizando vistas existentes como subvistas.
Los objetos de vista tienden a ser muy reutilizables y, por lo tanto, brindan coherencia entre aplicaciones.
Las plantillas de Action View se escriben utilizando Ruby incrustado en etiquetas mezcladas con HTML.
Una plantilla contiene las partes estáticas de la salida HTML deseada, así como una sintaxis especial que describe cómo se insertará el contenido dinámico.
Normalmente, las vistas comparten su nombre con la acción del controlador asociada...
...la vista conoce explícitamente el modelo y el controlador.
Actuar como mediador entre los objetos Modelo y los objetos Ver en una aplicación es un objeto Controlador.
En Rails, las solicitudes web son manejadas por el controlador de acciones y la vista de acciones.
Normalmente, el controlador de acciones se ocupa de comunicarse con la base de datos y realizar acciones CRUD cuando sea necesario.
Luego, Action View es responsable de compilar la respuesta.
En Django, una 'vista' describe qué datos se presentan, pero una vista normalmente delega a una plantilla, que describe cómo se presentan los datos.
El controlador es responsable de la interfaz entre el usuario y el modelo/vista. Interpreta los caracteres del teclado junto con los movimientos del mouse y los clics.
Normalmente, las vistas comparten su nombre con la acción del controlador asociada...
