Modelo-vista-controlador ( MVC ) es un patrón de diseño de software [1] que se utiliza habitualmente para desarrollar interfaces de usuario y que divide la lógica del programa relacionado en tres elementos interconectados. Estos elementos son:
Tradicionalmente utilizado para interfaces gráficas de usuario (GUI) de escritorio, este patrón 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 conceptos fundamentales en el desarrollo temprano 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 fines de la década de 1970. [6] [7] [8] : 330 Quería un patrón que pudiera usarse para estructurar cualquier programa en el que los usuarios interactuaran con un conjunto de datos grande y complejo . 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 modelo, vista y controlador. [6]
En su diseño final, un modelo representa una 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 de ida y vuelta entre el usuario y el modelo. Un controlador es una parte organizativa de la interfaz de usuario que presenta y coordina múltiples vistas en la pantalla, y que recibe la entrada del usuario y envía los mensajes apropiados a sus vistas subyacentes. Este diseño también incluye un editor como un tipo especializado de controlador utilizado para modificar una vista en 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 esta. [6] Proporciona clasesview abstractas y , así como varias subclases concretas de cada una que representan diferentes widgets genéricos . En este esquema, a representa alguna forma de mostrar información al usuario y a representa alguna forma en que el usuario puede interactuar con a . A también está acoplado a un objeto de 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, una vista y un controlador determinados uno al lado del otro. [9]controller Viewcontrollerviewview
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 desarrolladores de Smalltalk-80. Sin embargo, su esquema difería tanto del de Reenskaug et al. como del presentado por los libros de referencia de Smalltalk-80. Definieron una vista como algo que abarca cualquier aspecto gráfico, siendo un controlador un objeto más abstracto, generalmente invisible, que recibe la entrada del usuario e interactúa con una o varias vistas y un solo modelo. [10]
El patrón MVC evolucionó posteriormente, [11] dando lugar a variantes como el modelo-vista-controlador jerárquico (HMVC), el modelo-vista-adaptador (MVA), el modelo-vista-presentador (MVP), el modelo-vista-vistamodelo (MVVM) y otras 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 originalmente se escribió en Objective-C (que tomó prestado mucho de Smalltalk) y ayudó a aplicar los principios MVC. Más tarde, el patrón MVC se hizo popular entre los desarrolladores de Java cuando WebObjects se trasladó 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 presentó a MVC como un patrón donde 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 apropiada para su visualización. [8] : 56 Esto es cercano al enfoque adoptado por el marco de aplicación web Ruby on Rails (agosto de 2004), que hace que el cliente envíe 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 modelo apropiados. [12] El marco Django (julio de 2005, para Python ) propuso 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 plantillas para su visualización. [13] Tanto Rails como Django debutaron con un fuerte énfasis en la implementación rápida, 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] El modelo es esencial para mantener los datos organizados y consistentes. Asegura que los datos de la aplicación se comporten de acuerdo con las reglas y la lógica definidas.
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 la entrada del usuario. [20] Sin embargo, tanto en Smalltalk-80 como en WebObjects, las vistas están pensadas para ser de propósito 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 directamente un widget de interfaz de usuario. [23] [24] (Django opta por llamar a este tipo de objeto una "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 de Smalltalk-80 se comunican tanto con un modelo como con un controlador, [27] mientras que con WebObjects, una vista se comunica solo con un controlador, que a su vez se comunica 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 la entrada y la convierte en comandos para el modelo o la vista. [31]
Un controlador Smalltalk-80 maneja eventos de entrada del usuario, como pulsaciones de botones o movimientos del ratón. [32] En cualquier momento dado, cada controlador tiene una vista y un modelo asociados, aunque un objeto de modelo puede recibir información de muchos controladores diferentes. Solo un controlador, el controlador "activo", recibe la entrada del usuario en cualquier 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 solo 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 de modelo relevante y prepara una respuesta utilizando una vista. Convencionalmente, cada vista tiene un controlador asociado; por ejemplo, si la aplicación tuviera una clientvista, normalmente también tendría un Clientscontrolador asociado. Sin embargo, los desarrolladores son libres de crear otros tipos de controladores si lo desean. [35]
Django llama al objeto que desempeña esta función "vista" en lugar de 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 un modelo, una vista y un componente controlador, el patrón de diseño MVC define las interacciones entre estos tres componentes: [37]
Al igual que con otros patrones de software, MVC expresa el "núcleo de la solución" a un problema al tiempo que permite adaptarlo a cada sistema. [38] Los diseños MVC particulares 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 de Richard Pawson Naked Objects . [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 la informática de escritorio , MVC ha sido ampliamente adoptado como un diseño para aplicaciones de la 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 las responsabilidades de MVC se dividen entre el cliente y el servidor . [42] Los primeros marcos MVC adoptaron un enfoque de cliente ligero que colocaba casi toda la lógica del modelo, la vista y el controlador en el servidor. En este enfoque, el cliente envía solicitudes de hipervínculo o envíos de formularios al controlador y luego recibe una página web completa y actualizada (u otro documento) de 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 sola tabla de base de datos.
es responsable de proporcionar una representación visual del objeto.
Los objetos de vista representan elementos visibles en la interfaz de usuario (ventanas, por ejemplo, o botones).
[MVC] permite que las vistas se utilicen como partes para ensamblar 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, proporcionan coherencia entre aplicaciones.
Las plantillas de vista de acción se escriben utilizando Ruby integrado 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.
Por lo general, las vistas comparten su nombre con la acción del controlador asociada...
la vista conoce explícitamente el modelo y el controlador.
El objeto controlador actúa como mediador entre los objetos de modelo y los objetos de vista en una aplicación.
En Rails, las solicitudes web son manejadas por el controlador de acciones y la vista de acciones. Normalmente, el controlador de acciones se encarga de comunicarse con la base de datos y realizar acciones CRUD cuando sea necesario. La vista de acciones es entonces responsable de compilar la respuesta.
En Django, una "vista" describe qué datos se presentan, pero una vista normalmente delega en una plantilla, que describe cómo se presentan los datos.
modelo/vista. Interpreta los caracteres del teclado junto con los movimientos del mouse y los clics.
Por lo general, las vistas comparten su nombre con la acción del controlador asociada...
