Ahora que Cairngorm 3 desde hace un tiempo ya es una realidad, on este artículo queremos mostrar que es, que nos aporta respecto a sus versiones anteriores y daremos un vistazo a su evolución.

Las versiones anteriores de Cairngorm se basaban en una implementación específica del patrón Model-View-Controller, en cambio Cairngorm 3, debido a la experiencia, quiere darnos una serie de guías, buenas prácticas y nos aporta unas librerías y herramientas para ayudarnos en el desarrollo.
Esto implica que el paso de Cairngorm 2 a 3 no sea un simple un cambio de versión si no un cambio de paradigma.

El objetivo de Cairngorm 3 es dar unas bases para conseguir unos desarrollos limpios, consistentes, testeables y fácilmente escalables.

Arquitectura de Cairngorm

Para aproximarnos a un diseño simple y testeable, Cairngorm recomienda una arquitectura concreta para las aplicaciones Flex. Esta arquitectura tiene como objetivo que la estructura de la aplicación se desglose en pequeñas unidades de funcionalidad.

Antes de ver la separación arquitectural, entendamos como concibe Cairngorm una aplicación. Está compuesta de 3 capas de alto nivel:

• Capas de arquitectura: responsables de separar las clases según su responsabilidad
• Áreas funcionales: agrupan clases que atañen el mismo ámbito funcional
• Patrones de diseño: nos permiten coordinar los objetos de manera consistente

Capas de Arquitectura

Las clases con diferentes tipos de responsabilidad en las diferentes capas, pueden cambiarse separadamente por otras. De esta manera, si el diseño visual necesita ser ajustado, la mayoría de los cambios se limitan a clases de la capa de presentación y no a otras partes del código.

Cairngorm recomienda esta separación de capas según la responsabilidad general de cada una de ellas:

• Presentation: se encarga de la apariencia visual y del comportamiento de la presentación. Cairngorm recomienda el uso del patrón de presentación Presentation Model, que se encarga de controlar el estado y comportamiento de la capa de visualización.
• Application: coordina la presentación y la infraestructura de componentes. Coordina los componentes de distintas capas y los enlaza con los Domain Objects mediante el concepto de Controller que ya veremos.
• Domain: se centra en las tareas sobre el modelo de negocio. Representa una abstracción del mundo real mediante un modelo de datos. Sus responsabilidades suelen ser: la validación, cálculos sobre los datos, filtro, ordenación y formateo de datos…
• Infrastructure: coordina los objetos y su integración con otros sistemas, como el servidor y sus servicios remotos.

En la siguiente figura vemos la jerarquía de capas. De arriba hacia abajo, la comunicación entre una capa y su contigua es directa; en dirección contraria, la comunicación se realiza mediante eventos, callback functions u otras soluciones similares.

Áreas funcionales

Las aplicaciones se suelen dividir en diferentes áreas funcionales. La codificación de cada área funcional suele estar agrupada y separada de otras áreas funcionales, para que así sean desarrolladas y probadas de manera independiente. Podemos tener una aplicación de ejemplo que esté compuesta por tres áreas funcionales: contactos, mensajes y gastos. Entonces, cada una de estas áreas es subdividida según las distintas capas de arquitectura, según sea conveniente, como podemos ver en la siguiente imagen:

Cada área funcional suele estar contenida en un package. Ciertas áreas funcionales, según su grado de relación, pueden estar contenidas en un proyecto separado y así extraerse en módulos. El código que suele usarse en diferentes partes de la aplicación, como componentes, suelen ponerse dentro de un proyecto de librería.

Las áreas funcionales suelen tener sus capas de presentación y aplicación. A menudo contienen sus propias capas de dominio, pero otras veces comparten conocimiento del modelo de dominio de otras áreas. En este caso, estos modelos de dominio suelen ser encapsulados en proyectos de librería. Las áreas funcionales pueden interactuar con otras mediante interfaces y eventos AS3.

Capa de presentación

Presentation Model

Una de las cosas que nos recomienda Cairngorm 3 es tender a minimizar el código dentro de los mxml. Si es posible debemos intentar no tener código ni funciones, así las vistas reducen su tamaño y se centran solo en la disposición de sus componentes; haciendo más fácil la lectura.

La manera de hacerlo es extrayendo las variables y funciones que estarían en el Script-block en presentation models.
Cada componente o vista MXML significativa debe tener su propio presentation model. El PM se centra en el estado y comportamiento requeridos para representar los datos en la vista.

Un PM no debe saber nada de otro, ni de la vista relacionada ni de qué sirve a la aplicación. Un PM no debe tener referencia a la vista a la cual sirve, sino que es la vista que observa al PM relacionado. La comunicación entre ambos se realiza mediante Bindings o eventos.

Con esta aproximación minimizamos los errores en la vista y la lógica se localiza en el PM, que es fácilmente testeable.

Coordinación entre PMs

Cairngorm nos muestra dos entidades para coordinar los presentation models con otras entidades: Presenter y Controller. A continuación los vemos con mayor detalle.

Presenters

Su ámbito se centra en la capa de presentación. Se encarga de la coordinación local entre Presentation Models de una misma área funcional o de una región de ésta. Entendemos pues que su rol está por encima de los PMs.

Sus principales objetivos son:

Desacoplar la presentación del Dominio

Coordinación de PMs

Como vemos en la figura anterior, reducen el acoplamiento entre PMs y los domains, escuchando eventos procedentes de los domains y comunicándolos a los PMs.

También son usados para manejar los eventos procedentes de PMs y delegarlos a otros PMs.
Las razones que nos pueden motivar a usar Presenters son:

• Facilitan la lectura y control a alto nivel de la coordinación entre PMs
• Se encargan de asegurar el orden en la gestión de los eventos lanzados por los distintos PMs, ya que los mecanismos de mensajería, normalmente no suelen definir un orden
• Evitan el código de gestión de eventos (event-handling) en cada PM para escuchar a las peticiones de los otros

Controllers

Los Controllers se sitúan en la capa de Application. Tienen la responsabilidad de gestionar la coordinación general de los Presenters, no en un ámbito local, sino más global de un grupo específico de PMs. Se encargan de:

• Traducir los eventos procedentes de un área funcional a eventos de otras áreas funcionales
• Interceptar eventos a nivel de aplicación
• Traducir los eventos de aplicación a llamadas de la API de dominio con la finalidad de mantener los objetos de dominio libres de cualquier conocimiento relacionado con otras capas arquitecturales

En situaciones determinadas, los PMs pueden comunicarse directamente con los objetos de dominio y recibir sus cambios mediante eventos, como podemos ver en la siguiente figura:

Aplicaciones Modulares

La modularidad va más allá de los conceptos de Flex Module y ModuleLoader. Implica la separación de aplicaciones en unidades pequeñas que pueden ser desarrolladas y testeadas independientemente.

Beneficios de la Modularización

• Un modulo puede ser desarrollado, y probado con una relativa independencia
• Los tiempos de compilación se minimizan, ya que los cambios en un módulo no requieren de otros módulos
• Los módulos pueden ser cargados bajo demanda, lo que hace que la carga inicial de la aplicación es mucho menor
• Si un usuario no usa un determinado módulo, no es necesario cargarlo
• Se pueden cargar diferentes módulos para distintos usuarios, según sus privilegios
• Un modulo es más fácil de entender y mantener que una aplicación monolítica, consiguiendo una mejor cohesión funcional
• La interacción entre módulos puede determinarse con APIs, independientemente del crecimiento de la aplicación

Modularización y Cairngorm 3

Como hemos visto, una de las claves de Cairngorm 3 es separa las aplicaciones en diferentes áreas funcionales que pueden ser desarrolladas independientemente; viene a ser una arquitectura modular, donde cada área funcional sería un módulo. Cairngorm recomienda que la comunicación entre las distintas áreas funcionales se haga mediante APIs definidas por interfaces, eventos y DTOs. Así minimizamos las dependencias entre las distintas áreas.

Tendencia hacia el bajo acoplamiento

Cairngorm 3 da mucha importancia a que las capas arquitecturales tengan un mínimo acoplamiento, asumiendo que cada capa cambia por motivos diferentes. Con un bajo acoplamiento en las distintas capas, éstas pueden tolerar mejor el cambio. Por otro lado, el bajo acoplamiento tiene un precio: cuanto menos acoplado esté un objeto a otro, se incrementa la dificultad de lectura.
Hay distintas opciones para conseguir un bajo acoplamiento que los desarrolladores deben tener en cuenta.

Opciones para construir, recuperar y aislar objetos

La manera en que creamos, recuperamos o aislamos los objetos en una aplicación Flex, es un aspecto importante.
Por ejemplo, creando un objeto de dominio dentro de un PM, provocamos una dependencia directa. Implica que el objeto queda aislado y si otra parte de la aplicación requiere este objeto, no tendrá acceso directo para consultarlo.

Además con esta dependencia forzada con el objeto de modelo dentro del PM, estamos atando fuertemente la capa de presentación a una implementación concreta del dominio. Con una interface del dominio y usando eventos, podemos bajar el acoplamiento, desacoplando las capas arquitecturales.

La implementación de un objeto de dominio no puede cambiarse sin cambiar la implementación del PM, lo cual puede restringir la flexibilidad de la aplicación.
Los objetos de modelo tienen un significado a más alto nivel que el PM. Cuando el dominio puede abstraerse y controlarse con objetos de más alto nivel, conseguimos una inversión de control, que se opone a la aproximación usual de que objetos de bajo nivel controlan a otros.

Opciones de separación de la construcción y comportamiento de los objetos

Puede ser muy incómodo para el PM substituir el objeto de dominio con una implementación diferente cuando el PM crea al objeto de dominio. Puede también ser muy incómodo el hecho de recuperar una misma instancia del dominio en un determinado lugar de la aplicación. Tenemos diferentes opciones de separar la creación del comportamiento de un objeto para simplificarlo, a continuación mostramos las dos más comunes.

• Aproximación transversal: El modelo de dominio se instancia en el PM o Vista de más alto nivel y se va propagando jerárquicamente a las subvistas o PMs relacionados.
• Aproximación con framework de IoC: Se responsabilizan de la construcción de los objetos. El desarrollador especifica los objetos que se necesitan en el container de IoC.
  Así el framework IoC puede proporcionar estos objetos mediante inyección de dependencias o dependency lookup.

Librerías que nos proporciona Cairngorm

Cairngorm 3 proporciona diferentes librerías, alguna de ellas construidas sobre frameworks existentes como Parsley, Swiz y Spring ActionScript.
Estas librerías son interesantes, tenemos librerías para validación, para la gestión de popups, de navegación, gestión de módulos, etc. Recomiendo que leáis este apartado para que veáis que nos proporciona.

Para entender más como funciona Cairgorm 3 y los distintos conceptos, es necesario mirar y analizar un poco el código de las aplicaciones de ejemplo.

La información de Cairngorm 3 está en este link.

En según qué ocasiones podemos requerir que nuestra aplicación ejecute una serie de Commands de forma asíncrona siguiendo un órden determinado.
Cairngorm viene de serie con la capacidad de encadenar Commands asíncronamente. La clase com.adobe.cairngorm.commands.SequenceCommand es la que se ocupa de que esto sea posible.
En esta entrada veremos dos formas de implementar el secuenciado. Una de forma estática y la otra de forma dinámica.

Encadenado estático

De forma nativa Cairngorm soporta encadenado estático de Commands, esto significa que para una secuencia dada deberemos crear una serie de Commands exclusiva para ésta.
El principal problema que se nos puede plantear en este caso es que si queremos reutilizar un Command que ya forma parte de una secuencia no podremos. Nos veremos forzados a duplicar código.
La causa de este problema viene del hecho que la clase SequenceCommand, la clase de la que extienden nuestros Commands a secuenciar, utiliza una propiedad nextEvent que es la que decide cuál es el siguiente Evento (y por consiguiente Command) que se va a ejecutar. La forma en la que los Commands son lanzados hace que sea imposible parametizar esta propiedad y por lo tanto se mantega estática.

Un ejemplo de un Command que forma parte de una secuencia:

HolaCommand.as (ejemplo estático)

Encadenado dinámico

El encadenado dinámico es mucho más flexible que el estático dado que permite crear de forma dinámica las secuencias de Commands, de este modo podremos reutilizar un mismo Command para formar parte de diferentes secuencias o para ser lanzado individualmente.
Para conseguir este objetivo nos vamos a servir de una colaboración que Bjorn Schultheiss ha hecho al repositorio de recursos para Cairngorm: cairngormdocs.com.
Se trata de dos clases: com.bjorn.event.ChainEvent y com.bjorn.event.EventChainFactory.
La clase ChainEvent es un wrapper de com.adobe.cairngorm.control.CairngormEvent que añade la propiedad nextChainedEvent:ChainEvent, y la clase EventChainFactory es la que se ocupa de enlazar dinámicamente las diferentes instancias de eventos que queremos secuenciar. Se le pasa un Array de instancias de ChainEvent y va asignando de mayor a menor (en índice) cual es su nextEvent.

Un ejemplo de un Command que se añade dinámicamente a una secuencia, su evento relacionado y la forma de crear la secuencia:

HolaCommand.as (ejemplo dinámico)

HolaEvent.as (ejemplo dinámico)

Creación dinámico de la secuencia

Proyectos de ejemplo

Incluyo dos proyectos muy simples de ejemplo. Uno para secuenciado estático y otro para secuenciado dinámico:

Secuenciado estático de Commands

Secuenciado dinámico de Commands

Con la idea de preparar varias aproximaciones a la solución de un mismo problema he pasado la aplicación Flex Store simplificada desarrollada por Joan Garnet tanto a cairngorm como a guasax.

En la primera versión que desarrolló Joan mostraba en el ejemplo una serie de buenas practicas en cuanto a la organización de código y separación de conceptos dentro de una aplicación Flex simulando una Flex Store simplificada.

En este ejemplo vemos esa misma aplicación pasada, con los mínimos cambios posibles, a Cairngorm.

En primer lugar decir simplemente que debido al gran trabajo de joan , pasarlo a cairngorm ha resultado extremadamente directo, ya que la aplicación estaba muy preconcebida para ello.

Como punto de partida recomendamos leer nuevamente el articulo de Joan para centrar el tema de discusión.
En este articulo simplemente mostraremos algunos cambios relevantes en el código entre las dos versiones. Esperamos que tanto esta versión como la basada en guasax sirva como piedra de toque para la adopción de determinado framework, si todavía no utilizamos uno, entorno al cual organizar y hacer crecer nuestros proyectos de la mejor manera posible.

El ejemplo de la aplicación con (acceso al código fuente para descarga y visualización ) se puede ver aqui.

La podéis descargar directamente aquí como proyecto para importar directamente en Flex Builder , con la libreria de Cairngorm incluida.

Preparando el proyecto

Como podemos ver en la estructura de la aplicación, tenemos un directorio swclibs en el que tenemos la libreria swc de cairngorm que deberos cargar en el Flex Build Path de nuestra aplicación.
Además en el fichero principal de la aplicación , en este caso el Main.mxml, debemos cargar el Controlador que se encargará de crear y añadir los eventos necesarios para el funcionamiento de la aplicación:

Como podemos ver en el código, a través de la instrucción "control:Controller" inicializamos el singleton del Controller ,lo que hará que este declare los eventos, vincule los comandos que los van a atender , y los añada al FrontController. Una nota importante, si un evento no es añadido al FrontController , aunque lo disparemos , NO se ejecutará el Comando que tiene asociado. Por ello si disparáis un evento y veis que no se ejecuta el Comando asociado, revisar si habéis añadido esta relación en el Controller.
Una vez cargado el Controller, vemos que en el método inicializaModeloDeDatos lanzamos el primer evento para que se ejecute una acción. En la linea comentada podéis observar la forma de hacerlo en la versión anterior.

El controlador en Cairngorm

Cairngorm nos aporta un FrontController del cual podemos heredar para crear nuestro propio Controlador, en este controlador declararemos nuestros eventos y les asignaremos una clase Comando a cada uno de estos para que desarrollen su función.

Creación de las clases Evento y Commands

Partiendo de la clase Controlador del ejemplo inicial, en la que teníamos declarados los eventos que va a disparar la aplicación, así como los métodos que atienden a dichos eventos, podemos crear las clases comando para atender a cada uno de estos eventos que vamos a lanzar desde el código.
Las clases Evento tiene pocos cambios respecto a la version anterior, simplemente heredan de la clase de Cairngorm CairngormEvent, la que les permitirá entre otras cosas, poder disparase directamente sin necesidad de utilizar la clase CairngormEventDispatcher.
Para cada uno de los eventos y casos de uso que queremos lanzar en nuestra aplicación nos creamos una clase Comando. Para ello debemos implementar la interface ICommand.
Aqui podemos ver un ejemplo de uno de los comandos de la aplicación:

Los métodos que en el ejemplo anterior teníamos en el Controlador , los hemos encapsulado en clases comando. Si desde estas clases comando tenemos que realizar llamadas a servicios remotos , estas llamadas se delegan en un BusinessDelegate que es el encargado de hacer la invocación al servicio remoto.

Lanzando los eventos

Para lanzar los eventos de Cairngorm lo podemos hacer a través del CairngormEventDispatcher o directamente desde el propio evento , llamando al método dispatch();

Como podemos ver en esta porción de codigo:

vemos como desde una parte de la vista de nuestra aplicación, en el manejador del evento click, sobre un botón ponemos el disparo de algunos eventos. Desde el click del boton estamos desencadenando el evento que hará que se ejecute el comando que tenga asociado dicho evento, desde este comando llevaremos a cabo nuestra lógica de negocio , llamada a servicios remotos , y actualización de nuestro modelo de datos.

Conclusiones

En este ejemplo hemos podido ver como Cairngorm nos aporta una cierta organización de código en torno a unos patrones de diseño. En el ejemplo preliminar el codigo ya estaba organizado en torno a unas practicas programativas similares por lo que la diferencia no es excesiva. Cairngorm nos aporta como valía añadida un FrontController con alguna función añadida, una forma de definir y consumir servicios remotos (a través del ServiceLocator) y una forma de vincular una evento con una clase que implemente el patrón Comando.

En el siguiente post mostraremos el mismo ejemplo en guasax para empezar a trabajar en algunas de las problemáticas que se plantean cuando creamos proyectos con un volumen de clases considerable y debemos primar la reutilización de código así como la mantenibilidad de la aplicación.

Finalmente, agradecer a Joan las facilidades prestadas para utilizar su ejemplo como plataforma para trabajar este tipo de problemáticas en el desarrollo de aplicaciones Flex.

Enlaces y recursos

- Articulo de Joan con la primera versión del ejemplo Flex Store simplificado.

- Enlace online al ejemplo con opción de ver codigo fuente con el boton derecho del raton.

- Enlace para descarga del proyecto para importar directamente en Flex Builder con la librería de cairngorm incluida.

Hoy se ha sacado el segundo HotFix para Flex 2.0.1. Como siempre, se han solventado diferentes bugs que la gente ha ido reportando desde el HotFix 1.

Este HotFix se lanza en conjunción con la nueva versión de Flex Data Services, LiveCycle® Data Services ES 2.5.

Además, para aquellos que utilicéis Cairngorm, como algunas de las clases de Flex se han movido del SDK principal a LCDS, tambien se ha generado un nuevo release de Cairngorm a efectos de compatibilidad entre ambos.

Podéis descargaros el HotFix 2 en:

Flex 2.0.1 HotFix 2

Para quien utilice Cairngorm, podréis encontrar la nueva versión en:

Cairngorm

Presento un caso de uso de Cairngorm 2.2 incluyendo las últimas convenciones y funcionalidades. Ideal para iniciarse a la arquitectura por ser muy básico (es un formulario de Login).
El ejemplo consume servicios sobre AMFPHP 1.9 para poder mostrar también como pasar objetos tipados de Flex a PHP y viceversa.
Descargar ejemplo: Ejemplo Cairngorm 2.2 con amfphp 1.9 (Login)

Hace unos días apareció una pequeña actualización de la micro-arquitectura de patrones Cairngorm. La nueva versión 2.2 la podeis descargar desde su página en Adobe Labs. La principal novedad es la separación del framework base de la parte empresarial representada por los Live Cycle Data Services, de forma que no exitan dependencias. Es decir, ahora tendremos también un Cairngorm Enterprise que usaremos si trabajamos con Live Cycle Data Services.

Algunos cambios interesantes son:

• Los eventos son capaces de despacharse ellos mismos mediante el método "dispatch()". Ya no es necesario usar CairngormEventDispatcher.
• Como era de esperar la interface ModelLocator ha sido deprecada en favor de IModelLocator.
• Los comandos son añadidos al controlador con weak references de forma que el GC sea más efectivo. Además podemos eliminar commandos registrados en el FrontController mediante "removeCommand".
• Por fin los SWC ocupan unos pocos Kbs ya que no tienen las clases del framework de Flex linkadas.
• Se arregla un bug en los Web Services que hacian imposible cargar un WSDL

Podeis leer el resto en las release notes de Adobe Labs.

En una aplicación se suele tratar con muchos datos que se visualizan de forma distinta dependiendo del punto de la navegación en el que se encuentre el usuario. Además puede ser que un mismo conjunto de datos se muestre a la vez (gráfico + tabla). Supongamos el caso en el que se hace una petición a un service a través de un command y se pintan los mismos datos en una taba y en un gráfico estadístico. Si en una petición posterior los datos variasen se tendrían que actualizar todas las vistas dependientes.

Con el fin de no tener que gestionar todos los destinos de un mismo modelo de datos, se afronta el desarrollo de un ModelLocator, que viene a ser un repositorio común de datos implementado en forma de Singleton (GoF). Si un comando actualiza un determinado conjunto de datos las vistas que utilizan esos datos, serán notificadas, actualizando así su representación. Esto se hace a través de Bindings.

El ModelLocator no suele tener mucha lógica y en muchos casos se puede reducir a una clase con múltiples propiedades (modelo de datos de la aplicación). El acceso de escritura sobre estos atributos se reserva (por convenio) a los commands, que cargarán en las propiedades los valores recibidos del servidor.

Una vez los datos estén censados en el ModelLocator, y casi siempre a través de Bindings, las distintas vistas suscritas a ellos se actualizarán de forma automática. Es una buena práctica que siempre que queramos hacer cambios sobre nuestras vistas, lo hagamos en el modelo de tal forma que los cambios se propaguen a todas las dependencias visuales que existan.

Tal y como comentamos en el punto de eventos, los bindings funcionan siguiendo el principio del patrón Observer (GoF). Con lo cual podríamos ver el ModelLocator como la entidad encargada de gestionar el modelo consumidor / productor de datos. Los commands serían productores de datos mientras que las distintas vistas serían los consumidores de éstos mismos.

Con este artículo cerramos la serie teórica sobre Cairngorm. Espero en breve empezar con la serie de casos de usos prácticos. Dejo aquí links a todos los artículos de la serie.

1. Cairngorm I: Introducción.
2. Cairngorm II: Value Objects.
3. Cairngorm III: Commands.
4. Cairngorm IV: FrontController.
5. Cairngorm V: Eventos.
6. Cairngorm VI: Services y ServiceLocator.
7. Cairngorm VII: Business Delegate.
8. Cairngorm VIII: Model Locator.

En el post anterior vimos que los commands son stateless y que son el núcleo funcional de las distintas partes de una aplicación. Poniendo el ejemplo de "cargar los datos de un usuario dadoï¿Â½? veamos cómo abordaríamos su implementación a alto nivel.

El command tendría que utilizar un service que le permitiera establecer una conexión con la parte servidora. Si por ejemplo tenemos una página .aspx, .jsp, .php, un servlet, etc que pasándole como parámetro un id nos devuelve en formato xml la información de un usuario. Tendríamos que declarar este service en nuestro serviceLocator.

Posteriormente podríamos invocar la petición desde cualquier command. Veamos un pequeño ejemplo:

La implementación podría quedar así y sería totalmente válida. Pero fijémonos que en ningún lado hemos hablado de lo que se hará una vez se obtenga la respuesta de la invocación del servicio. Seguramente un servicio o un método de este pueda invocarse de distintas formas (comando) y cada una de ellas tratará los resultados de una forma distinta.

Vemos entonces que la invocación de los servicios tiene que parametrizar siempre la forma de tratar la respuesta. Para solventar esto se introduce el concepto de Responder. A nivel implementacional no es más una interface que define un método result y otro fault que se ejecutarán cuando el resultado de la invocación del service sean satisfactoria o no.

Paralelamente a este problema en un desarrollo distribuido cliente/servidor normalmente trabajan distintos perfiles: especialistas cliente y especialistas servidor. Es muy normal que las fases de desarrollo cliente / servidor se paralelicen, de tal forma que el desarrollo de la parte cliente pueda continuar sin necesidad de que la parte servidora esté completa.
Esta es una de las justificaciones del patrón Business Delegate, el cual permite crear una capa temporal que gestione las respuestas y que en determinadas situaciones pueda simular una parte del aplicativo aún por desarrollar devolviendo Mock Objects (Objetos generados de forma hard coded que emulan una posible respuesta).

Resumiendo, los Business Delegate nos permiten gestionar la forma en cómo tratar las respuestas recibidas desde el servidor así como el simularlas agilizando el desarrollo.

Tal como comentábamos en el punto uno (Value Objects), en un aplicativo se debería tratar siempre con ValueObjects transversales a la tecnología utilizada en las distintas capas, es conveniente tratar con objetos que no comprometan el futuro de nuestras aplicaciones. Tal como comentábamos aunque nuestro aplicativo consuma datos dinámicos en formato XML, SOAP, etc. es muy interesante convertirlos a VO’s. Los delegates al tener el control sobre las invocaciones al servidor y a sus respuestas, es el sitio ideal donde hacer el tratamiento de la información recibida y por ejemplo parsear de XML a VO’s.

Los delegates también son la parte que aislan la aplicacición de la tecnología utilizada en el servidor. Si tenemos un aplicativo que consume datos en formato XML y queremos pasar a utilizar FDS o cualquier otra solución basada en AMF sólo tendríamos que cambiar el delegate.
Veamos un ejemplo de un delegate:

Un uso muy potente que podríamos dar a los delegates consistiría en definirlos implementando una interface. Si tenemos varias implementaciones, estas serían intercambiables. Si en los commands referenciármos al delegate a través de su interface y no a través de su implementación concreta obtendríamos un sistema capaz de consumir los mismos datos pero a partir de fuentes distintas. Esta solución se podría usar por ejemplo en sistemas de alto tráfico donde en determinados momentos convendría consumir datos de forma dinámica (FDS, xml dinámico a partir de .phh, .asp, .jsp, servlets, etc) o a partir de ficheros estáticos en formato xml previamente generados en el servidor.

Tal como comentábamos en el último artículo un Command es transversal a las capas de influencia. Aunque un command esté especializado en una tarea muy concreta, esta tarea puede afectar al modelo, a la capa visual o a la capa de negocio.

Es normal que muchos de los commands afecten al modelo de datos, el cual podríamos ver como una capa compartida entre cliente y servidor, introduciendo así el canal de comunicación. Si por ejemplo realizamos una petición al servidor para cargar datos en formato xml, estos datos (modelo) quedarán cargados en el cliente pero los ha facilitado el servidor (modelo compartido).

Por ejemplo, un comando podría ser el responsable de grabar los datos obtenidos a través de un formulario en una tabla de una BBDD (persistencia de datos) pasando a través de algún DAO. Al tratarse de una aplicación cliente, ésta desconoce 100% la lógica interna de la aplicación servidora que almacenará esta información (DAO). La aplicación cliente sólo sabe qué parámetros va a necesitar su homólogo en la parte servidora. Es por ello que desde el lado cliente se recogen los datos y se delega en la parte controladora del lado del servidor la serialización y la persistencia así como el resto de tareas asociadas a la BBDD de estos datos.

La parte cliente se ocupará de gestionar la transacción con el servidor (que la comunicación sea satisfactoria), que los datos tengan coherencia e integridad (filtros y validadores) y de pasarle en un formato conocido por ambas partes los datos necesarios (VO’s si usamos RemoteObject, XML si usamos HttpService o SOAP).

Introducimos el concepto de Servicio como el homólogo, en la parte cliente, de la business logic de servidor. Por ejemplo el servidor es el responsable y conocedor de cómo trabajar con la BBDD a través de DAO’s (Data Access Objects), de cómo crear nuevos registros, modificarlos y eliminarlos. En la parte cliente existe su homólogo pero en vez de saber cómo realizar estas acciones directamente, sabe cómo delegar la responsabilidad a la parte servidora. En algunos casos se utilizará HTTPService en otros RemoteObject o WebService, etc.

Por ejemplo, en el cliente tenemos un formulario de alta de usuario. Los campos de este formulario se tienen que terminar serializando en una BBDD. La forma en que podríamos hacerlo:

• Si la aplicación servidora está basada en URL’s (dependiendo de los parámetros se ejecuta una acción u otra sobre los datos) como por ejemplo Spring, Struts, etc. nuestra aplicación constaría de un servicio HTTPService que referenrenciaría a la url pertinente.
• Si la aplicación servidora funciona sobre FDS, openAMF, amfPHP, etc. nuestra aplicación constaría de un service por cada una de las clases mapeadas.
• Si la aplicación servidora consiste en un servicio SOAP, nuestra aplicación constaría de un servicio WebService.

Estos servicios simplemente ejecutan el código en el servidor pasándole los parámetros que requieran y recogen la respuesta que el servidor genere.

Estos servicios tienen que ser accesibles desde cualquier parte de la aplicación y tienen que ser únicos. Esto es, si queremos invocar dos veces a un servicio SOAP con paremetrización diferente y desde puntos distintos de nuestra aplicación no tendríamos que reinstanciar a los servicios.
Para evitar la duplicidad de los servicios introducimos el patrón ServideLocator que implementa una singleton garantizando así una existencia única.

A través del ServiceLocator podremos acceder así a los servicios disponibles (declarados) para la aplicación sin tener que declararlos una y otra vez. Garantizando así la escalabilidad de su mantenimiento y la facilidad para el cambio (p.e cambio en la url de los servicios o un cambio de mapping).

En los últimos meses el uso de ViewHelpers ha ido disminuyendo en las aplicaciones creadas con Cairngorm. Otros frameworks del estilo como ARP, nunca llegaron a soportar esta estrategia debido a la propia naturaleza de las aplicaciones Flash (creadas con ActionScript 2.0), donde los objetos visuales estaban atados a su representación en la pantalla y podían soportar su propia API sin necesidad de clases de apoyo.

Hoy en día, una aproximación más acertada y elegante sería usar el tag Observer de Paul Williams para provocar la llamada de ciertos métodos en la vista cuando cambie alguna parte de nuestro modelo.

El tag Oberver es una clase muy simple y pequeña (de hecho, Paul la propone como "el tag más pequeño del mundo"):

Podemos instanciar esta pequeña clase en nuestra vista de la siguiente forma:

Como podeis observar, si consideramos que "model" es nuestro ModelLocator, cuando "myProperty" cambia de valor los bindings provocarán que se ejecute la función myFunction de nuestra vista.