Modelo–vista–controlador

Un diagrama sencillo que muestra la relación entre el modelo, la vista y el controlador. Nota: las líneas sólidas indican una asociación directa, y las punteadas una indirecta (por ejemplo, patrón Observer).

Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista.

Historia

El patrón fue descrito por primera vez en 1979​ por Trygve Reenskaug, entonces trabajando en Smalltalk en laboratorios de investigación de Xerox. La implementación original está descrita a fondo en Programación de Aplicaciones en Smalltalk-80(TM): Como utilizar Modelo Vista Controlador.​

Descripción del patrón

• Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.
• Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.
• Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca cambios en el modelo y, probablemente, en la vista.

Muchos sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos: en líneas generales en MVC corresponde al modelo. La unión entre capa de presentación y capa de negocio conocido en el paradigma de la Programación por capas representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio de capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí.

Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente:

1. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.)
2. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.
3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista.
5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

Frameworks MVC

Lenguaje	Licencia	Nombre
Ruby	MIT	Ruby on Rails
Java / J2ee	Apache	Struts
Java / J2ee	Apache	Beehive
Java / J2ee	Apache	Spring
Java / J2ee	Apache	Tapestry
Java / J2ee	Apache	Aurora
Java / J2ee	Apache	JavaServerFaces
Perl	GPL	Catalyst
Perl	GPL	CGI::Application
Perl	GPL	Gantry Framework
Perl	GPL	Jifty
Perl	GPL	Maypole
Perl	GPL	OpenInteract2
Perl	Comercial	PageKit
Perl	GPL	Cyclone 3
Perl	ECL	Solstice
Perl	GPL	CGI::Builder
PHP	GPL	Self Framework
PHP	LGPL	Tlalokes
PHP	LGPL	Agavi
PHP	BSD	Zend Framework
PHP	MIT	CakePHP
PHP	GNU/GPL	KumbiaPHP
PHP	MIT	Symfony
PHP	MIT	QCodo
PHP	GNU/GPL	CodeIgniter
PHP	Otra	Kohana
PHP	MPL 1.1	PHP4ECore
PHP	BSD	PRADO
PHP	GNU	FlavorPHP
Python	ZPL	Zope3
Python	Varias	Turbogears
Python	GPL	Web2py
Python	BSD	Pylons
Python	BSD	Django
.NET	Castle Project	MonoRail
.NET	Apache	Spring .NET
.NET	Apache	Maverick .NET
.NET	MS-PL	ASP.NET MVC
.NET	Microsoft Patterns & Practices	User Interface Process (UIP) Application Block
AS3	Adobe Open Source	Cairngorm