MODELO VISTA CONTROLADOR
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 enaplicaciones 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 loseventos de entrada desde la vista
FINALIDAD DEL MVC
La finalidad del modelo es mejorar
la reusabilidad por medio del desacople entre la vista y el modelo.
El modelo es el responsable
de:
1. Acceder a la capa de almacenamiento
de datos. Lo ideal es que el modelo sea independiente del sistema de
almacenamiento.
2.
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”.
3. Lleva un registro de las vistas y
controladores del sistema.
4.
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).
El controlador es el responsable de:
1. Recibe los eventos de entrada (un
clic, un cambio en un campo de texto, etc.).
2. 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 )”.
Las vistas son responsables de:
1. Recibir datos del modelo y los
muestra al usuario.
2. Tienen un registro de su controlador
asociado (normalmente porque además lo instancia).
3. 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).
·
Ventajas que trae utilizar el MVC
1. Es posible tener diferentes vistas
para un mismo modelo (eg. representación de un conjunto de datos como una tabla
o como un diagrama de barras).
2. Es posible construir nuevas vistas
sin necesidad de modificar el modelo subyacente.
3. Proporciona un mecanismo de
configuración a componentes complejos muchos más tratable que el puramente
basado en eventos (el modelo puede verse como una representación estructurada
del estado de la interacción).
Orígenes del mvc
Basado en información histórica,
puede decirse que este fue descrito por primera vez en 1979 por Trygve
Reenskaug, trabajador de Smalltalk, en unos laboratorios de gran investigación
de Xerox.
·
Flujo que sigue el control en una implementación general de un MVC
Aunque se pueden encontrar
diferentes implementaciones de MVC, el flujo que sigue el control generalmente
es el siguiente:
·
El usuario interactúa con la interfaz de usuario de
alguna forma (por ejemplo, el usuario pulsa un botón, enlace)
·
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.
·
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.
·
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
·
La interfaz de usuario espera nuevas interacciones del
usuario, comenzando el ciclo nuevamente.
·
MVC tiene por objeto separar la lógica del negocio de
las consideraciones de la interfaz de usuario para que los desarrolladores
puedan modificar cada parte más fácilmente sin afectar a la otra. En MVC el
modelo representa la información (los datos) y las reglas del negocio; la vista
contiene elementos de la interfaz de usuario como textos, formularios de
entrada; y el controlador administra la comunicación entre la vista y el
modelo.
·
Más alla del MVC, Yii tambien introduce un
front-controller llamado aplicación el cual representa el contexto de ejecución
del procesamiento del pedido. La aplicación resuelve el pedido del usuario y la
dispara al controlador apropiado para tratamiento futuro.
El patrón de arquitectura
"modelo vista controlador", es una filosofía de diseño de
aplicaciones, compuesta por:
1.
Modelo
Contiene el
núcleo de la funcionalidad (dominio) de la aplicación.
Encapsula el
estado de la aplicación.
No sabe nada
/ independiente del Controlador y la Vista.
2.
Vista
Es la
presentación del Modelo.
Puede
acceder al Modelo pero nunca cambiar su estado.
Puede ser
notificada cuando hay un cambio de estado en el Modelo.
3.
Controlador
Reacciona a
la petición del Cliente, ejecutando la acción adecuada y creando el modelo
pertinente para entender cómo funciona nuestro patrón Modelo vista controlador,
se debe entender la división a través del conjunto de estos tres elementos y
como estos componentes se comunican unos con los otros y con otras vistas y
controladores externos a el modelo principal. Para ello, es importante saber
que el controlador interpreta las entradas del usuario (tanto teclado como el
ratón), enviado el mensaje de acción al modelo y a la vista para que se proceda
con los cambios que se consideren adecuados
4.
Comunicación
El modelo, la vista y el controlador deben comunicarse
de una manera estable los unos con los otros, de manera que sea coherente con
las iteraciones que el usuario realizara. Como es lógico la comunicación entre
la vista y el controlador es bastante básica pues están diseñados para operar
juntos, pero los modelos se comunican de una manera diferente, un poco más
sutil
5.
Modelo pasivo
No es necesario para el modelo hacer ninguna tener
alguna disposición a él, simplemente basta con tener en cuenta su existencia.
El modelo no tiene ninguna responsabilidad para comunicar los cambios a la
vista porque ocurren solo por orden del usuario, por lo que esta función la
llevara a cabo el controlador porque será el que interprete las ordenes de este
usuario debido a que solo debe comunicar que algo ha cambiado. Por esto, el modelo
es se encuentra en modo inconsciente y su participación en este caso es
irrisoria.
6.
Unión del modelo con la vista y el controlador
Como no todos los modelos pueden ser pasivos,
necesitamos algo que comunique al controlador y a la vista, por lo que en este
caso, si que necesitamos el modelo, ya que solo este puede llevar a cabo los
cambios necesarios al estado actual en el que estos se encuentran.
Al contrario que el modelo,
que puede ser asociado a múltiples asociaciones con otras vistas y
controladores, cada vista solo puede ser asociada a un único controlador, por lo que han de tener una
variable de tipo controler que notificara a la vista cual es
su controlador o modelo asignado. De igual manera, el controlador tiene una
variable llamada View que apunta a la vista. De esta manera,
pueden enviarse mensajes directos el uno al otro y al mismo tiempo, a su
modelo.
Al final, la
vista es quien lleva la responsabilidad de establecer la comunicación entre los
elementos de nuestro patrón MVC. Cuando la vista recibe un mensaje que
concierne al modelo o al controlador, lo deja registrado como el modelo con el
cual se comunicara y apunta con la variable controller al
controlador asignado, enviándole al mismo su identificación para que el
controlador establezca en su variable view el identificador de
la vista y así puedan operar conjuntamente. El responsable de deshacer estas
conexiones, seguirá siendo la vista, quitándose a si misma como dependiente del
modelo y liberando al controlador.
7.
Implementación del Modelo Vista
Controlador: Structs
Para mejorar la reutilización, extensibilidad,
flexibilidad y el resto de elementos de las aplicaciones, proponemos el uso se
puede usar el siguiente patrón de diseño, entendiendo que este es un descriptor
de objetos y clases adaptadas para resolver un problema.
Una aplicación basada en Struts, tiene un componente
básico llamado ActionServlet. Este es un servlet, que tramita las peticiones de
los clientes delegando a un componente definido por el usuario por cada
petición. Este Servlet es el punto central del framework, aunque no es
necesario que todas la actividad fluya a través de él. En una aplicación basada
en Struts se pueden hacer peticiones a una JSP que contengan o no "tag
libraries" de Struts, sin pasar por el Servlet ActionServlet.
El ActionServlet (controlador) de Struts captura y
encamina las peticiones HTTP que llegan a la aplicación (toma la decisión de a
dónde enviar la petición HTTP), a otros componentes de aplicación. Estos
componentes pueden ser páginas JSP o instancias de una subclase de la clase
org.apache.struts.action.Actionque el propio framework suministra.
Cuando se inicia el Servlet ActionServlet, carga y
analiza la información de un fichero que contiene la configuración de la
aplicación para aplicar las características de Struts. Entre otras cosas, el
fichero de configuración define las correspondencias que existen entre las
peticiones HTTP que captura el Servlet controlador y las acciones que van a
tratar esa petición. Estas correspondencias son manipuladas como instancias de
la clase org.apache.struts.action.ActionMapping
El navegador lanza una petición HTTP a la aplicación,
evento que es capturado por el servidor de aplicaciones y encaminado al
componente correspondiente del modelo vista controlador para su tratamiento.
