Cairngorm Framework
v2.2
Mate Framework
• Prototipos rápidos
• Aplicación con
compleja o repetitiva
lógica
• Independencia en el
desarrollo de UI de la
lógica de negocio
• Reusar aplicaciones
Flex
PureMVC Framework
• Aplicación con
compleja o repetitiva
lógica
Cairngorm Framework
• Equipo nuevo en el
desarrollo de Flex
• Prototipos rápidos
Mas Frameworks
•
•
•
•
•
Slide
ARP
Foundry
Guasax
…
Patrón MVC
• Modelo: representación de la información
que va a ser manipulada o visualizada
• Vista: presentación del modelo en formato
adecuado (interfaz de usuario)
• Controlador: control de acciones por parte
del usuario y cambios del modelo
Introduccion
• Framework estructural desarrollo de RIA’s
• Ventajas:
•
•
•
•
•
Minimiza curva aprendizaje
Aplicar conocimiento ya adquirido
Reutilización de código
Aceptado por la industria
Soportado por Adobe
Value Object
• LN dependiente del MD  gran
dependencia
• VO
• Ortogonalidad y baja cohesión
• Sin lógica de negocio
• Simples contenedores de datos
• Ejemplo:
• Diferentes origines de datos
• Mismo tratamiento de objetos
Commands
• Muchos objetos especializados mejor que
pocos y poco especializados
• Poseen la lógica de negocio
• Independientes de lo visual, lo importante
es lo funcional (unidad mínima funcional)
• Se pueden encadenar
• Encapsuladores de lógica de negocio 
intercambiables
FrontController
• Centralizar invocaciones de comandos
• Invocación a través de eventos
• Suscripción de comandos a eventos 
FrontController es listener
Events
• EventDispatcher + Listener = Observer
• Parametrización de invocaciones a
comandos  eventos customizados
• Información de conjunto de invocaciones o
casos de uso
• Evento = ejecución de comando
• Eventos almacenables
• Comandos reutilizables
Services y ServiceLocator
• Homólogo de la lógica de negocio en la parte cliente
• Servidor  responsable y conocedor de cómo trabajar con
la BBDD
• Cliente  cómo delegar la responsabilidad a la parte
servidora
• HttpService
• WebService
• RemoteObject
• Accesibles y únicos
• ServiceLocator
• Evitar duplicidad
• Escalabilidad mantenimiento
• Facilidad para el cambio
BusinesDelegate
• Necesidad de un servicio por parte del comando
para conectar con la parte servidora
• Independencia entre desarrollos cliente/servidor
• Gestionar tratamiento de respuestas de los
comandos
• Uso potencial
• Definición a través de interfaces para intercambio de
implementaciones según necesidades
ModelLocator
• Datos a visualizar en diferentes puntos de
navegación o en diferentes formas
• Repositorio común de datos
• Los comandos modifican este conjunto de datos y
las vistas se actualizan de forma automática
(bindings)
• Modificar el modelo  modifiquen las vistas
• Gestión del modelo consumidor / productor de
datos
• Consumidor  vistas
• Productor  comandos
(De)Serialización + Sesión
• dpHibernate
• Serializador/Deserializador de objetos
• Propiedades
• Getters y Setters
• Flex – Java – Flex
• Tuning  evitar “lazy loading”
• Sesión
• Peticiones Flex  Gestores  Home
• Una única sesión
• 1 o n transacciones
• Transacción con Spring
• Definición de “puntos de corte” + “asesores”
• Lanzamiento de excepciones  rollback
Arquitectura
Descargar

Slide 1