Download Componentes

Diseño y Desarrollo de
Software
Model View Controller
Architecture
Dra. Marcela
Capobianco
1
¿Qué es MVC?
Model View Controller (MVC) es un patrón
agregado 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
En este caso la vista es la página HTML y el
código que provee de datos dinámicos a la
página
Componentes
Modelo: representación específica del
dominio de la información sobre la cual
funciona la aplicación.
La lógica de dominio añade significado a los
datos. Ejemplo: calcular los importes en un
carrito de compras
Vista: presenta el modelo en un formato
adecuado para interactuar, usualmente un
elemento de interfaz de usuario.
Componentes
Controlador: responde a eventos,
usualmente acciones del usuario, e invoca
cambios en el modelo y probablemente en
la vista.
Muchas aplicaciones utilizan un mecanismo
de almacenamiento (base de datos)
MVC no menciona específicamente esta
capa de acceso a datos.
De donde surge
En general una aplicación tiene tres capas
principales: presentación (UI), dominio,
acceso a datos
MVC divide la capa de presentación en
controlador y vista.
Existen muchas implementaciones
diferentes de MVC que en general siguen el
mismo flujo de control
Flujo de control
1.El usuario interactúa con la interfaz (por
ejemplo, el usuario pulsa un botón)
2.El controlador recibe (por parte de los
objetos de la interfaz-vista) la notificación
de la acción del usuario (gestor de
eventos)
3.El controlador accede al modelo,
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)
Flujo de control
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 (ej: produce un listado del
Flujo de control
El modelo no debe tener conocimiento
directo sobre la vista.
El patrón de observador puede ser utilizado
para proveer cierta indirección entre el
modelo y la vista
Esto permite al modelo notificar a los
interesados de cualquier cambio.
Un objeto vista puede registrarse con el
modelo y esperar a los cambios, aun así el
modelo en sí mismo sigue sin saber nada
Flujo de control
El controlador no pasa objetos de dominio
(modelo) a la vista aunque puede dar la
orden a la vista para que se actualice.
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 espera nuevas interacciones
del usuario, comenzando el ciclo
nuevamente.
Flujo de control
El paradigma MVC crea al objeto
controlador entre la vista y el modelo para
ocmunicarse.
La implementación del controlador puede
variar pero la idea es transformar eventos
en cambios en los datos
Relación con patrones de
diseño
MVC separa el modelo de las vistas
Un mismo modelo puede tener varias vistas
asociadas
Recordemos: patrón Observer
•Intención: Define una dependencia entre objetos de
uno-a-muchos de forma tal que cuando un objeto
cambia de estado, todos sus dependientes son
notificados y actualizados acordemente.
•Alias: Dependents, Publish-Suscribe
•Aplicabilidad: Usaremos este patrón cuando:
• Cuando una abstracción tiene dos aspectos, uno
independiente del otro.
• Cuando un cambio a un objeto requiere cambios en
otros, y no sabemos cuántos objetos necesitan ser
cambiados.
• Cuando un objeto debería notificar a otros objetos sin
realizar suposiciones de quiénes son esos objetos (evitar
el acoplamiento)
Patrón Observer
Patrón Observer
•Estructura de colaboración
Relación con patrones de
diseño
Para desconectar las vistas del modelo se
utiliza el patrón observer
Las vistas en MVC pueden estar anidadas
Un panel de control puede contener
botones tal que c/u es implementado como
una vista
Se usa una subclase de view llamada
compositeview
Queremos tratar a compositeview de la
misma forma que se trata a sus
Recordemoa: patrón
Composite
•Intención: Compone objetos en estructuras de árbol
para representar jerarquías de relación “es-partede”.
•Aplicabilidad: Usaremos este patrón cuando:
• Queremos representar jerarquías de objetos
modelando la relación “es-parte-de” (part-whole
hierarchies)
• Queremos que el cliente ignore la distinción
entre objetos compuestos y objetos individuales. El
cliente tratará todos los objetos de la estructura
compuesta de manera uniforme.
Patrón Composite
Patrón Composite
• Component: declara la interfaz para los objetos
en la composición.
• Implementa el comportamiento por defecto
para todos los objetos.
• Declara la interfaz para acceder y manipular
los componentes hijos.
• Opcionalmente implementa una interfaz para
acceder al padre.
Patrón Composite
• Leaf: representa los objetos simples en la
composición. Define el comportamiento de
tipos primitivos.
• Composite: define el comportamiento para
componentes compuestos. Almacena estos
componentes e implementa operaciones
relacionadas a su administración.
• Client: Manipula los objetos en la composición
por medio de la interfaz Component.
Este patrón simplifica la implementación del
cliente
Relación con patrones de
diseño
Queremos tratar a compositeview de la
misma forma que se trata a sus
componentes
Para esto usamos el patrón composite
También permite cambiar la forma que una
vista responde al usuario sin cambiar su
representación visual
Basta con reemplazar la instancia del
controlador
Patrón Strategy
•Intención: Define una familia de algoritmos,
encapsula cada uno convirtiéndolos en
intercambiables. Permite variar un algoritmo
independientemente de los clientes que lo utilizan.
•Alias: Policy
•Aplicabilidad: Usaremos este patrón cuando:
• Muchas clases relacionadas difieren únicamente en el
comportamiento.
• Necesitamos diferentes variantes de un algoritmo.
• Un algoritmo utiliza datos que el cliente no debe
conocer.
• Una clase define múltiples comportamientos, y éstos
figuran como sentencias condicionales múltiples en sus
Patrón Strategy - Estructura
Patrón Strategy
•Participantes:
• Strategy: declara una interfaz común a todos los
algoritmos soportados.
• ConcreteStrategy: implementa un algoritmo
utilizando la interfaz Strategy.
• Context: está configurado con un objeto de tipo
ConcreteStrategy. Mantiene una referencia a un
objeto Strategy. Puede definir, si es necesario,
una interfaz para que Strategy acceda a sus
datos.
Relación con patrones de
diseño
El patrón Strategy nos permitirá cambiar la
instancia del controlador aún en tiempo de
ejecución
Por ejemplo, una vista puede ser
desabilitada simplemente creando una
instancia de controller que ignora los
eventos de entrada
Análisis
Siempre hay que considerar si es la opción
más conveniente para la situación dada
Posee ventajas dado que la estabilidad del
modelo no es la misma que la de la vista
Si el modelo fue construido correctamente
es en general bastante estable
Esto no es cierto para la interfase
Separarlos hace que el modelo sea más
robusto
Implementaciones
Fue descripto por primera en 1979 por
Trygve Reenskaug
El autor trabajaba para Xerox research labs
sobre Smalltalk
La implementación original se describe en:
Applications Programming in Smalltalk80(TM):How to use Model-View-Controller.
Implementaciones
Esta implementación inspiró a muchos
otros como:
•
Cocoa y GNUstep, usan MVC.
•
Microsoft Foundation Classes (MFC).
•
Java Swing GUI library.
•
Qt Toolkit desde Qt4 Release.
Más recientemente se lo ha propuesto
como solución para aplicaciones Web
Implementaciones
Implementaciones más populares
orientadas a la web:
JavaServer Faces
Apache Struts
Webwork2
Apache Struts está orientado a las páginas
enteras y JSF a un nivel de componentes
Java Server Faces
JavaServer Faces (JSF) es un application
framework basado en Java
Simplifica el desarrollo de interfases para
aplicaciones Java EE
JSF usa JavaServer Pages como display
technology y puede acomodar otras
tecnologías:
Java Server Faces
JSF incluye:
Un conjunto de APIs paa representar
componentes de la interfaz de usuario,
manejar su estado, eventos, entrada,
accesibilidad, internacionalización
Conjunto default de UI
Dos librerias JavaServer Pages (JSP) para
disponer de un interfase JSF en un página
JSP.
Server-side event model
Objetivos de diseño
Crear un framework de componentes GUI
estandard que pueda hacer más facil para
los usuarios de los tools desarrollar GUIs y
manejar las conexiones con el
comportamiento
Definir un conjunto de clases básicas para
GUI components, component state, y
eventos de entrada.
Proveer un modelo JavaBeans para enviar
eventos desde el client-side GUI al serverside application behavior.
Objetivos de diseño
Definir APIs para validación de la entrada,
incluyendo soporte para client-side
validation
Especificar un model para internationalición
y localización de la GUI
Generación automatica de salida apropiada
para el cliente (tomando en cuenta
configuration data, browser version, etc).
Struts
Estuvo dentro del Jakarta Project y
actualmente es un proyecto top level
Es un open-source framework para
desarrollar Java EE aplicaciones web
Usa y extiende el API Java Servlet para
fomentar el uso de la architectura MVC
Fue creado originalmente por Craig
McClanahan y donado a la Apache
Foundation en el 2000
Struts
Permite el diseño e implementación de
grandes aplicaciones web por grandes
grupos de desarrolladores
Diseñadores de páginas, componentes y
otros desarrolladores pueden trabajar en
forma desacoplada
Incorpora I18N (internationalization), form
validation y variedad de presentation
layers: JSP, XML/XSLT, JavaServer Faces
(JSF)
También model layers:JavaBeans and EJB.