CONCEPTO Modelo Vista Controlador (MVC) es un patrón 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.[4] RESEÑA HISTORICA El Model-View-Controller (Modelo-Vista-Controlador, en adelante MVC) fue introducido inicialmente en la comunidad de desarrolladores de Smalltalk-80. Ademas 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. [4] Según uno de los Sistemas de Patrones de Arquitectura más extendido en el mundo: Pattern Oriented Software Architecture, publicado por Buschmann en 1996, el patrón que se analiza en este trabajo (MVC), se sitúa en la tercera de las cuatro categorías en las cuales clasifica a los patrones: Del barro a la estructura (From mud to Structure), Sistemas Distribuidos (Distributed Systems), Sistemas Interactivos (Interactive Systems) y Sistemas Adaptables (Adaptable Systems). De igual forma si utilizamos otro de los sistemas más difundidos: Pattern of Enterprise Application Architecture, descrito recientemente por Fowler en el pasado 2003, lo ubica en la tercera de las siete categorías que se mencionan a continuación: Patrones de lógica del dominio (Domain Logia Patterns), Patrones de Mapeo a Bases de Datos Relacionales (Mapping to Relational Database Patterns), Patrones de Presentación Web (Web Presentation Patterns), Patrones de Distribución (Distribution Patterns), Patrones de Concurrencia Offline (Offline Concurrency Patterns), Patrones de Estado de Sesión (Session State Patterns) y Patrones Base (Base Patterns).[2] DESCRIPCION MODELO Para el diseño de aplicaciones con sofisticados interfaces se utiliza el patrón de diseño Modelo-Vista-Controlador. La lógica de un interfaz de usuario cambia con más frecuencia que los almacenes de datos y la lógica de negocio. Si realizamos un diseño ofuscado, es decir, un pastiche que mezcle los componentes de interfaz y de negocio, entonces la consecuencia será que, cuando necesitemos cambiar el interfaz, tendremos que modificar trabajosamente los componentes de negocio. Mayor trabajo y más riesgo de error.
Se trata de realizar un diseño que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lógica de negocio o de datos. [1] DESCRIPCION DE CAPAS Un modelo puede tener diversas vistas, cada una con su correspondiente controlador. Un ejemplo clásico es el de la información de una base de datos, que se puede presentar de diversas formas: diagrama de tarta, de barras, tabular, etc. [1] MVC divide una aplicación interactiva en 3 áreas: procesamiento, salida y entrada. Para esto, utiliza las siguientes abstracciones: •
Modelo (Model): Encapsula los datos y las funcionalidades. El modelo es independiente de cualquier representación de salida y/o comportamiento de entrada. [2] El modelo es el responsable de: Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento. Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: "Si la mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar del proveedor". Lleva un registro de las vistas y controladores del sistema. Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero bath que actualiza los datos, un temporizador que desencadena una inserción, etc). [1]
•
Vista (View): Muestra la información al usuario. Pueden existir múltiples vistas del modelo. Cada vista tiene asociado un componente controlador. [2] Las vistas son responsables de: Recibir datos del modelo y los muestra al usuario. Tienen un registro de su controlador asociado (normalmente porque además lo instancia). Pueden dar el servicio de "Actualización()", para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes). [1]
•
Controlador (Controller): Reciben las entradas, usualmente como eventos que codifican los movimientos o pulsación de botones del ratón, pulsaciones de teclas, etc. Los eventos son traducidos a solicitudes de servicio ("service requests") para el modelo o la vista. [2] El controlador es responsable de: Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.). Contiene reglas de gestión de eventos, del tipo "SI Evento Z, entonces Acción W". Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al método "Actualizar()". Una petición al modelo puede ser "Obtener_tiempo_de_entrega( nueva_orden_de_venta )". [1]