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