Cairngorm VIII: Model Locator

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.

Xavi es un Technical Arquitect de Aplicaciones RIA basadas en la Plataforma Flash trabajando para Adobe en Londres. Especializado en aplicaciones colaborativas en tiempo real, e-learning y CMS (Content Management Systems) utiliza Flex, LCDS, BlazeDS, FMS y Java principalmente.

Sitio Web:http://www.code4net.com

7 Comentarios

  1. Ernesto Pino

    Impresionante y a la vez sencilla, la forma en que Xavi nos hace llegar sus conocimientos sobre Cairngorm.

    Muchas gracias Xavi por esta joya de artículo.

  2. xleon

    Joé, menuda cacho de didactica cojonuda. No todo el mundo tiene tu capacidad de expresar conceptos complejos de manera tan simple. Me toca empezar con Cairngorm, y creo que este ha sido un buen punto de partida.
    Muchas gracias

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acerca de Made In Flex

Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

Últimas Fotos

Instalador de Apache Flex

Entrar o Registrase