Introduccin El diseo es un modelo del sistema, realizado con una serie de principios y tcnicas, que permite describir el sistema

con el suficiente detalle como para ser implementado. Pero los principios y reglas no son suficientes, en el contexto de diseo podemos observar que los buenos ingenieros tienen esquemas y estructuras de solucin que usan numerosas veces en funcin del contexto del problema. Este es el sentido cabal de la expresin "tener un mente bien amueblada", y no el significado de tener una notable inteligencia. Estos esquemas y estructuras son conceptos reusables y nos permiten no reinventar la rueda. Un buen ingeniero reutiliza un esquema de solucin ante problemas similares. Segn Martin Fowler: Cada patrn describe un problema que se produce una y otra vez en nuestro entorno y, a continuacin describe el ncleo de la solucin a ese problema, de tal forma que puede utilizar esta solucin millones de veces, sin hacerlo de la misma manera dos veces Los patrones de diseo son el esqueleto de las soluciones a problemas comunes en el desarrollo de software. En otras palabras, brindan una solucin ya probada y documentada a problemas de desarrollo de software que estn sujetos a contextos similares. Debemos tener presente los siguientes elementos de un patrn: su nombre, el problema (cuando aplicar un patrn), la solucin (descripcin abstracta del problema) y las consecuencias (costos y beneficios). Es un patrn de arquitectura de las aplicaciones software Separa la lgica de negocio de la interfaz de usuario Facilita la evolucin por separado de ambos aspectos Incrementa reutilizacin y flexibilidad 1. 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 mercanca pedida no est en el almacn, consultar el tiempo de entrega estndar 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 insercin, etc.).

2. El controlador es responsable de: Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.). Contiene reglas de gestin de eventos, del tipo "SI Evento Z, entonces Accin W". Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al mtodo "Actualizar ()". Una peticin al modelo puede ser "Obtener tiempo de entrega ( nueva orden de venta )".

3. Las vistas son responsables de: o Recibir datos del modelo y la muestra al usuario. o Tienen un registro de su controlador asociado (normalmente porque adems lo instancia). o Pueden dar el servicio de "Actualizacin ()", 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).

Un ejemplo de MVC con un modelo pasivo (aquel que no notifica cambios en los datos) es la navegacin web, que responde a las entradas del usuario, pero no detecta los cambios en datos del servidor. El diagrama de secuencia:

Pasos:

1. El usuario introduce el evento. 2. El Controlador recibe el evento y lo traduce en una peticin al Modelo (aunque tambin puede llamar directamente a la vista). 3. El modelo (si es necesario) llama a la vista para su actualizacin. 4. Para cumplir con la actualizacin la Vista puede solicitar datos al Modelo. 5. El Controlador recibe el control. Ventajas: La aplicacin esta implementada modularmente. Sus vistas muestran informacin actualizada siempre. El programador no debe preocuparse de solicitar que las vistas se actualicen, ya que este proceso es realizado automticamente por el modelo de la aplicacin. Si se desea hacer una modificacin al modelo del dominio, como aumentar mtodos o datos contenidos, solo debe modificarse el modelo y las interfaces del mismo con las vistas. Las modificaciones a las vistas no afectan en absoluto a los otros mdulos de la aplicacin. MVC es bastante utilizado en la actualidad en marcos de aplicacin orientados a objeto desarrollados para construir aplicaciones de gran tamao. MVC est demostrando ser un patrn de diseo bien elaborado pues las aplicaciones que lo implementan presentan una extensibilidad y una mantenibilidad nicas comparadas con otras aplicaciones basadas en otros patrones.

Desventajas El tiempo de desarrollo de una aplicacin que implementa el patrn de diseo MVC es mayor, al menos en la primera etapa, que el tiempo de desarrollo de una aplicacin que no lo implementa, ya que MVC requiere que el programador Implemente una mayor cantidad de clases que en un entorno de desarrollo comn no son necesarias. Sin embargo, esta desventaja es muy relativa ya que posteriormente, en la etapa de mantenimiento de la aplicacin, una aplicacin MVC es muchsimo mas mantenible, extensible y modificable que una aplicacin que no lo implementa. MVC requiere la existencia de una arquitectura inicial sobre la que se deben construir clases e interfaces para modificar y comunicar los mdulos de una aplicacin. Esta arquitectura inicial debe incluir, por lo menos: un mecanismo de eventos para poder proporcionar las notificaciones que genera el modelo de aplicacin; una clase Modelo, otra clase Vista y una clase

Controlador genricas que realicen todas las tareas de comunicacin, notificacin y actualizacin que sern luego transparentes para el desarrollo de la aplicacin. MVC es un patrn de diseo orientado a objetos por lo que su implementacin es sumamente costosa y difcil en lenguajes que no siguen este paradigma.