Modelo-vista-controlador

Modelo-vista-controlador (MVC) es un patrón de diseño de software comúnmente utilizado para desarrollar interfaces de usuario que divide la lógica del programa relacionado en tres elementos interconectados. Esto se hace para separar las representaciones internas de la información de las formas en que se presenta y acepta la información del usuario.

Usado tradicionalmente para interfaces gráficas de usuario (GUI) de escritorio, este patrón se hizo popular para diseñar aplicaciones web. Los lenguajes de programación populares tienen marcos MVC que facilitan la implementación del patrón.

Historia

Una de las ideas fundamentales en el desarrollo temprano de las interfaces gráficas de usuario, MVC se convirtió en uno de los primeros enfoques para describir e implementar construcciones de software en términos de sus responsabilidades.

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. Quería un patrón que pudiera usarse para estructurar cualquier programa en el que los usuarios interactúen con un conjunto de datos grande e intrincado. 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.

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, recuperando datos del Modelo para mostrarlos al usuario y pasando solicitudes entre el usuario y el Modelo. Un controlador es una parte organizativa de la interfaz de usuario que presenta y coordina varias 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 que se usa para modificar una Vista en particular, y que se crea a través de esa Vista.

Smalltalk-80 admite una versión de MVC que evolucionó a partir de esta. Proporciona clases View y Controller abstractas, así como varias subclases concretas de cada una que representan diferentes widgets genéricos. En este esquema, una Vista representa alguna forma de mostrar información al usuario, y un Controlador representa alguna forma para que el usuario interactúe con una Vista. Una View también está acoplada a un objeto modelo, pero la estructura de ese objeto se deja en manos del programador de la aplicación. El entorno de Smalltalk-80 también incluye un "MVC Inspector", una herramienta de desarrollo para ver la estructura de un modelo, una vista y un controlador dados uno al lado del otro.

En 1988, un artículo en The Journal of Object Technology (JOT) de dos ex-empleados de PARC presentó MVC como un "paradigma y metodología de programación" 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 que cubre cualquier preocupación gráfica, 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 solo un modelo.

El patrón MVC evolucionó posteriormente, 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 las aplicaciones web creció después de la introducción de WebObjects de NeXT en 1996, que se escribió originalmente en Objective-C (que se basó en gran medida en 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 transfirió a Java. Los marcos posteriores para Java, como Spring (lanzado en octubre de 2002), continuaron con 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 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. Esto es similar al enfoque adoptado por el marco de la 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. El framework Django (julio de 2005, para Python) presentó un "MTV" (Vista de plantilla de modelo) toma el patrón, en el que una vista recupera datos de modelos y los pasa a plantillas para su visualización. 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.

Componentes

Modelo

El componente central del patrón. Es la estructura de datos dinámica de la aplicación, independiente de la interfaz de usuario. 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 al programador. Con WebObjects, Rails y Django, un tipo de modelo normalmente representa una tabla en la base de datos de la aplicación.

Ver

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. 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. Sin embargo, tanto en Smalltalk-80 como en WebObjects, las vistas están destinadas a ser de propósito general y componibles.

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. (Django opta por llamar a este tipo de objeto una 'plantilla' a la luz de esto). Este enfoque pone relativamente menos énfasis en las vistas pequeñas que se pueden componer; una vista típica de Rails tiene una relación de uno a uno con una acción de controlador.

Las vistas de Smalltalk-80 se comunican tanto con un modelo como con un controlador, mientras que con WebObjects, una vista se comunica solo con un controlador, que luego se comunica con un modelo. Con Rails y Django, un controlador/vista utiliza una vista/plantilla al preparar una respuesta para el cliente.

Controlador

Acepta la entrada y la convierte en comandos para el modelo o la vista.

Un controlador Smalltalk-80 maneja los eventos de entrada del usuario, como presionar botones o mover el mouse. En un momento dado, cada controlador tiene una vista y un modelo asociados, aunque un objeto modelo puede escuchar de muchos controladores diferentes. Solo un controlador, el "activo" controlador, 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 responsable de indicarle a sus vistas que se actualicen.

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.

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 tipo de modelo tiene un controlador asociado; por ejemplo, si la aplicación tuviera un modelo Client, normalmente también tendría un controlador Clients asociado. Sin embargo, los desarrolladores son libres de crear otros tipos de controladores si así lo desean.

Django llama al objeto que desempeña este rol una "vista" en lugar de un controlador. Una vista de Django es una función que recibe una solicitud web y devuelve una respuesta web. Puede usar plantillas para crear la respuesta.

Interacciones

Además de dividir la aplicación en estos componentes, el diseño modelo-vista-controlador define las interacciones entre ellos.

• El modelo es responsable de gestionar los datos de la aplicación. Recibe la entrada de usuario del controlador.
• La vista presenta la presentación del modelo en un formato particular.
• El controlador responde a la entrada del usuario y realiza interacciones en los objetos del modelo de datos. El controlador recibe la entrada, lo valida opcionalmente y luego pasa la entrada al modelo.

Al igual que con otros patrones de software, MVC expresa el "núcleo de la solución" a un problema permitiendo adaptarlo a cada sistema. Los diseños particulares de MVC pueden variar significativamente de la descripción tradicional aquí.

Motivación

Como escribió Alan Kay en 2003, la motivación original detrás de MVC era permitir la creación de una interfaz gráfica para cualquier objeto. Eso se describe en detalle en el libro Naked Objects de Richard Pawson.

Trygve Reenskaug, creador de MVC en PARC, ha escrito que "MVC se concibió como una solución general al problema de los usuarios que controlan un conjunto de datos grande y complejo".

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 de MVC al estilo de Smalltalk-80 como:

• independencia de presentación y datos, por ejemplo, múltiples opiniones sobre un modelo simultáneamente,
• widgets de presentación composable, por ejemplo, una vista utilizada como subvisión de otra,
• modos de entrada intercambiables, intercambiando un controlador para otro durante el tiempo de ejecución, y
• independencia del procesamiento de insumos y productos, a través de las responsabilidades separadas de los controladores y opiniones.

Uso en aplicaciones web

Aunque se desarrolló originalmente para computadoras 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. 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 completa y actualizada (u otro documento) de la vista; el modelo existe completamente en el servidor. Los marcos posteriores han permitido que los componentes de MVC se ejecuten parcialmente en el cliente, utilizando Ajax para sincronizar datos.