En la fase de diseño estructural de un desarrollo Flex se deben tener en cuenta varios factores como la organización, intercomunicación y división lógica de las vistas.
Este caso de estudio está enfocado a desarrolladores Flex noveles que quieran conocer una forma de plantear sus arquitecturas de manera modular.

Organización y división lógica de las vistas

Una aplicación Flex suele estar compuesta por varias vistas, cada una de ellas, a su vez, puede estar formada por otras sub-vistas anidadas. Es una buena práctica separar dichas vistas en componentes lo suficientemente pequeños (y lo suficientemente grandes) como para que describan una funcionalidad concreta.
Las diferentes vistas de una aplicación se deben separar en unidades de funcionalidad (con significado), de este modo la estructura será más legible, será más sencillo detectar posibles errores y potenciaremos la reutilización.

Intercomunicación vistas-aplicación

Nuestra aplicación Flex en todo momento dispone de un estado (modelo). Dicho estado queda definido por el contenido de las variables que alimentan a los componentes: dataProviders, selectedItems, etc... La manera recomendada de enlazar el modelo de la aplicación con su representación gráfica (vista) es a través de data binding. Para ello mantendremos el modelo de datos centralizado en un lugar y enlazaremos a él todas las vistas mediante data binding.
Si queremos acabar de aislar nuestras vistas deberemos tener el cuidado de dejar abierto un canal a través del cual la aplicación pudea ser notificada de acciones y no delegar directamente a la vista esta tarea. Conseguiremos esto haciendo que nuestras vistas lancen eventos. Preferiblemente eventos personalizados con un significado acorde con la acción que lo lanzó. Por ejemplo, al cambiar la seleccion en un listado de productos podríamos lanzar un evento "seleccionDeProducto".
Es interesante también centralizar el lugar donde se van a recibir dichos eventos. Para ello crearemos una clase (Controlador) que se ocupará exclusivamente de escuchar todos los eventos de la aplicación y ejecutar las acciones que sean pertinentes.

Así pues, resumiendo, por un lado tendremos que enlazar nuestras vistas al modelo de datos y por otro, si la vista permite interacción, ésta dispondrá de un mecanismo de notificación de eventos para que el controlador de la aplicación pueda registrarse a ellos.

Un posible flujo a seguir:

1. Crear la estructura del proyecto
2. Detectar las vistas principales.
3. Crear el modelo de datos.
4. Desglosar cada vista principal en sub-vistas.
5. Definir los eventos y crear el controlador.

Vamos a tomar como ejemplo una tienda virtual tipo el Flex Store de Adobe (muy simplificado).

1. Crear la estructura del proyecto

En este proyecto vamos a definir la siguiente estructura de carpetas:

• control: aquí guardaremos el archivo correspondiente a nuestra clase Controlador, que se ocupará de escuchar los eventos que las vistas lancen y llevará a cabo las acciones que sean necesarias.
• event: en esta carpeta guardaremos todos los eventos personalizados que tengamos que crear.
• model: aquí guardaremos la clase de nuestro modelo de datos y todas las clases que pudean estar relacionadas.
• view: la carpeta view es donde debemos guardar todos los archivos .mxml (y .as de soporte) que representen las diferentes vistas y sub-vistas en la aplicación.
• vo: Los VOs ([1] Value Object) son pequeñas clases sin lógica (solo propiedades) que representan entidades en la aplicación. En la carpeta vo guardaremos todos los Value Objects que sean necesarios.

2. Detectar las vistas principales

La aplicación empieza en una vista con un listado de productos, una zona para ver el detalle del producto y una zona para almacenar el pedido, cuando acabamos el pedido vamos a otra vista donde se nos pide la información de pago y desde donde se puede enviar el pedido.
Todo esto suma 2 vistas principales: La vista de creación del pedido y la vista de proceso del pedido.

3. Crear el modelo de datos.

Simplificando mucho, el modelo de datos de una aplicación de e-commerce podría estar compuesto por: productos, productoSeleccionado y productosAdquiridos y totalPedido.
ModeloDeDatos.as

4. Desglosar cada vista principal en sub-vistas

En este momento ya podemos diferenciar tres archivos para las vistas: La vista de creación del pedido CreacionPedido.mxml, la vista donde se procesa la petición del pedido ProcesarPedido.mxml y el archivo principal donde se cargaran todas las vistas de la aplicación Main.mxml.
La vista CreacionPedido.mxml se puede desglosar en tres sub-vistas: El selector de productos SelectorProductos.mxml, el detalle del producto DetalleProducto.mxml y el panel del pedido acumulado PedidoAcumulado.mxml.
La vista ProcesarPedido.mxml se puede desglosar en tres sub-vistas: El formulario de envío de datos de pago FormEnvioDatos.mxml, la pantalla de envío satisfactorio EnvioSatisfactorio.mxml y la pantalla de envío erróneo EnvioErroneo.mxml.
Ésta es la estructura de vistas final en el proyecto de Flex Builder:

Éste es el código de los archivos principales:
Main.mxml

CreacionPedido.mxml

ProcesarPedido.mxml

Como se puede ver, una de las ventajas de trabajar con mxml es que se pueden incluir las sub-vistas como componentes, de manera que las podemos separar en diferentes archivos obteniendo así una organización mucho más intuitiva y legible.

5. Definir los eventos y crear el controlador.

Una vez tenemos las vistas y sub-vistas creadas nos es fácil intuir como éstas se van a comunicar con la aplicación. Es decir, qué eventos van a lanzar.
El proceso es el siguiente: una vista lanza un evento, el controlador lo capta, éste llama al método que tenga definido como handler, que ejecuta una serie de acciones que modifican el modelo de datos y, como las vistas están enlazadas mediante data binding, éstas se actualizan automáticamente.
Para entender mejor esta colaboración revisaremos el código de una vista y una parte del controlador.
SelectorProductos.mxml

Controlador.as (parcial)

En SelectorProductos.mxml podemos ver que el DataGrid selectorProductos tiene un evento change definido que a su vez lanza un evento ProductoEvent.PRODUCTO_SELECCIONADO del controlador pasando como parámetro el producto que se ha seleccionado.
En Controlador.as vemos que estamos escuchando al evento que nos interesa ProductoEvent.PRODUCTO_SELECCIONADO y que cuando éste se ejecuta llama a un método productoSeleccionado que actualiza el modelo. El resultado final es que el mecanismo de data binding actualizará todas las vistas que estén registradas a la propiedad del modelo que se modificó, en este caso productoSeleccionado, que hará que la vista DetalleProducto.mxml muestre el detalle del producto seleccionado.
Este mismo flujo se aplica en el resto de vistas.
Si nuestra aplicación acaba teniendo muchas vistas y eventos o simplemente necesitamos agregar/quitar funcionalidades veremos que esta arquitectura nos facilita mucho la tarea.

• Ver [2] aplicación de ejemplo
• [3] Descargar proyecto de ejemplo