Estoy agradecido a Cairngorm porque, en su día, fue un buen punto de partida y, a muchos, nos ha introducido en el mundo de los RIA y de Flex por el camino de las buenas prácticas.
Sin embargo, después de varios meses aplicándolo descubres que tiene sus inconvenientes: Cairngorm requiere mucho código repetitivo y, en ocasiones, es demasiado "retorcido" en situaciones que no lo justifican. Entonces, te empiezas a preguntar si quizá existe una arquitectura mejor, que requiera menos código y que te permita concentrarte más en la aplicación y menos en los detalles de implementación.
En esta entrada indagaré en las alternativas que existen en éste momento y seleccionaré las mejores candidatas a suceder a Cairngorm.
Para empezar, voy a tratar de enumerar las debilidades de Cairngorm y cuales deberían ser, desde mi punto de vista, las características de su sucesor.
Las debilidades de Cairngorm
Cualquiera que utilice Cairngorm lo ha sufrido; hay que escribir un montón de código repetitivo: el evento, el comando, el BusisnessDelegate,… y ya sabemos que más código significa más trabajo para mantenerlo.
Se abusa de los singletons, lo que hace que la aplicación sea más monolítica y los componentes estén demasiado acoplados; por ejemplo, los comandos son difícilmente reutilizables. En Java hace ya tiempo que los abandonamos (ServiceLocator, ModelLocator, etc.) en favor de otras técnicas como el IoC.
Por otro lado, para hacer que los componentes de las vistas sean algo más reutilizables se aconseja no usar los singletons en los componentes internos y hacerlo solo en los componentes de nivel superior. Esto implica que debemos utilizar variables para propagar los datos desde las vistas de nivel superior a los componentes mas internos y eventos para el recorrido inverso. Esto implica que muchos componentes manejan datos que no utilizan, solo para pasárselos a un componente de nivel superior o inferior.
No hay una solución limpia para implementar las acciones de usuario que implican la ejecución de varias tareas asíncronas. Los comandos encadenados son un parche y no una verdadera solución para este caso de uso[1].
Aunque Cairngorm pretende separar las responsabilidades y establecer la metodología y el modelo de programación, en muchos casos es ambiguo y los programadores tienen problemas para identificar cuando una variable es de estado o del modelo, cuando se puede actuar directamente sobre la vista o hay que utilizar un evento-comando, etc.
Otro aspecto que no me gusta, es que utiliza un sistema de despachado de eventos propio. No comprendo la necesidad de hacer esto cuando Flex dispone de una gestión de eventos muy completa y eficiente.
Finalmente, aunque es posible conseguir una aplicación modular con Cairngorm, la solución no es inmediata. En mi caso fue necesario modificar algunas de las clases del núcleo para conseguir algo parecido a una aplicación modular.
Los requisitos
El nuevo framework debe aportar soluciones a las debilidades de Cairngorm, empezando por abandonar el uso de singletons y facilitar el desacoplamiento de los componentes. Una buena alternativa es el uso de IoC que, como luego veremos, está empezando a ser muy común también en los frameworks de Flex.
Debe reducir y simplificar el código de modo que el programador no se pierda en los detalles de la implementación y pueda centrarse en la funcionalidad.
También sería deseable que facilite la construcción de aplicaciones modulares y que utilice al máximo las características propias de Flex. Después de todo Flex es, en sí, un framework de aplicación y lo que buscamos es una arquitectura y unas utilidades que nos faciliten la vida[2].
Por último, debe facilitar los unit tests y el uso de mock objects y, por supuesto debe ser open source y, como para cualquier otro software, es deseable que disponga de buena documentación, de una comunidad de desarrolladores activa, que tenga gran implantación y perspectivas de continuidad.
Alternativas descartadas
Flex adquirió popularidad con el lanzamiento de la versión 2 en 2006. Por aquel entonces muchos decidimos utilizar Cairngorm porque prácticamente era el único framework de arquitectura disponible. Desde entonces, es sorprendente la cantidad de alternativas que han surgido.
Dado el número de candidatos, he descartado aquellos que, a primera vista, no cumplen los requisitos o que, estudiados más de cerca, no parecen aportar ventajas significativas respecto a Cairngorm.
La lista de candidatos rechazados es la siguiente:
ARP
Es uno de los mas veteranos, ya que se venía usando en aplicaciones Flash, y es genérico para AS2/AS3.
Servebox Foundry
Incluye ciertas prestaciones de alto nivel como browsing (navegación), globalización, búsquedas y control de acceso, para lo cual debes usar subclases de sus propios objetos aplicación, form, etc.
Es un conjunto de soluciones, incluyendo parte servidor, que utilizaba la empresa ServerBox en sus desarrollos y que han decidido convertir en un proyecto open source.
Flicc
Es un implementación IoC basada en MXML.
No resuelve nada en el resto de aspectos (MVC, comunicación con el servidor, etc).
Flest
Utiliza closures como comandos.
Conserva muchos de los puntos débiles de Cairngorm.
Parece que no hay actividad desde Agosto del 2007.
Flex IOC
Como Flicc, es solo una implementación del patrón IoC, pero con anotaciones y en menos de 100 líneas de código.
Lo conozco hace tiempo y creo que fue el primero en utilizar anotaciones (probablemente sea el origen de la idea).
Gaia
Está orientado a aplicaciones Flash (AS2/AS3).
Guasax
Se basa en una filosofía similar a Struts, donde los acciones se declaran en XML (los métodos de los Business Objects).
Dispone de interceptores para las llamadas y de una gestión de roles de usuarios.
Reduce el código, al eliminar el evento y el comando de Cairngorm, sustituyéndolo por llamadas con arrays y el XML de acciones, y moviendo el código del comando y el BusinessDelegate a los Business Objects.
El uso de XML y de arrays hace que el compilador no pueda ayudarnos en la detección de errores de tipo.
En resumen, sigue utilizando singletons pero reduce el código repetitivo.
La última actualización es de Septiembre de 2007.
Model-Glue: Flex
Creado a partir de una versión para ColdFusion.
Utiliza clases helper e invocación implícita para eliminar código repetitivo (los componentes lanzan eventos que recoge el contenedor).
Tiene escasa documentación y el proyecto parece estar detenido en una versión Alpha.
MVCS
No es un framework, es un diseño o blueprint.
Parsley (SpiceFactory)
Incluye IoC basado en XML, MVC y prestaciones de localización (vía XML).
Tiene los componentes esenciales para ser una buena plataforma y, además, dispone de muy buena documentación, pero faltan herramientas básicas para el trabajo con RemoteObjects. Esto se debe a que la misma empresa distribuye un componente servidor llamado Cinnamon Remoting que tiene sus propios mecanismos de acceso.
Puede que en el futuro sea una opción interesante.
Penne
Otra simplificación de Cairngorm (en este caso quizá una sobre-simplificación).
El autor tiene obsesión por la pasta y utiliza nombres del estilo "getPastaTypes" o "IPastaRemoteRequest". En fin…
Prana
Es una implementación IoC basada en Spring y XML. Creo que fue la primera y, probablemente, es la mas establecida y la más documentada.
Lo interesante es que tiene soporte para Cairngorm y PureMVC.
El uso de XML y contextos de aplicación puede ser aplicable para crear aplicaciones modulares.
PureMVC/Flex
Quizá sea el framework MVC para Flex más adoptado después de Cairngorm.
Esta muy bien documentada, pero se trata de una implementación neutral disponible para varios lenguajes, de modo que no utiliza a fondo las prestaciones de Flex en cuanto a gestión de eventos o bindings.
Utiliza algunos singletons como el ServiceLocator ya que no hace uso de IoC.
En http://www.techper.net/2008/10/05/4-things-to-hate-about-puremvc/ se describen algunos otros defectos.
La descarto, no sin muchas dudas, por que intuyo que la curva de aprendizaje es larga y que, además, no va a simplificar la programación. Al contrario, me temo que su adopción implicaría meternos en un mar de patrones que "formalmente" sería lo aconsejable, pero en la práctica puede ser excesivo.
Slide
La documentación es casi nula.
Smartypants IOC
De nuevo una implementación de IoC pero, a diferencia de la mayoría, está basada en la filosofía de Guice y no en Spring.
VEGAS
Se trata de un conglomerado de librerías para AS1/2/3. Entre ellas encontramos implementaciones de patrones MVC e IoC.
Los finalistas
Después de la primera criba, estos son mis dos finalistas: Mate y Swiz.
Por el camino he abandonado otras opciones que no descarto retomar si estos dos no están a la altura de mis expectativas. Sin embargo, los dos tienen aspectos interesantes y novedosos que los hacen merecedores de un estudio en profundidad.
Mate
Mate es uno de los nuevos frameworks que últimamente ha adquirido una gran popularidad. Seguramente es el más adoptado después de Cairngorm y PureMVC.
Mate no impone un patrón, sino que ofrece una serie de herramientas que te permiten crear aplicaciones RIA con MVC de una forma no intrusiva, es decir, observando el código no encontrarás referencias al framework. Es el framework quien, desde "fuera", gestiona las clases de tu aplicación utilizando técnicas de IoC.
Para ello se utiliza un fichero MXML central, el EventMap, que incluye los tags que definen como se va a comportar tu aplicación. Por ejemplo, mediante el tag Injectors es posible inyectar valores en la vistas tras obtener del servidor los resultados de una petición.
Además, Mate es un proyecto muy activo y dispone de suficiente documentación.
El único aspecto negativo que puedo intuir en este momento es que los EventMaps pueden llegar a ser muy extensos y difíciles de interpretar en aplicaciones grandes, al estilo de lo que venía ocurriendo con Spring.
Estos son algunos enlaces que te pueden ser útiles para conocer un poco mejor este framework:
- La presentación en vídeo.
- Artículo de flashmagazine.com.
- Otra revisión.
- Un artículo que destaca sus puntos débiles.
- Un diagrama de su arquitectura.
Swiz
Es probablemente el framework mas innovador y mas reciente, pero ya ha cautivado la atención de la comunidad de desarrolladores de Flex (y la mía también).
Se basa en un núcleo IoC que utiliza ficheros MXML llamados BeanLoaders para definir los componentes (al estilo Spring) y anotaciones para definir los puntos de inyección (por lo que no es necesario el uso de XML). Esto, de entrada, elimina la necesidad de singletons explícitos.
Cuando creamos una vista, el contendor de IoC detecta que se ha añadido un componente al stage y automáticamente inyecta las variables necesarias sin necesidad de código adicional; simplemente anotando la variable con Autowire.
Por si esto fuera poco, además, incluye una serie de utilidades que permiten trabajar con las llamadas asíncronas de una forma muy cómoda y poco aparatosa gracias a las clases DynamicCommand y DynamicResponder que se crean bajo demanda "en el aire". Incluso puedes encadenar varias llamadas asíncronas con la clase CommandChain.
También dispone de una anotación Mediate que permite asociar los eventos con las funciones que los atienden en el controlador, por medio de lo que el autor llama DynamicMediators. Esto elimina también el típico código que llama a una función al recibir el evento.
En la gestión de eventos no reinventa la rueda y utiliza la infraestructura de Flex, lo cual hace el framework aún menos intrusivo.
En esencia, en una aplicación Swiz solo intervienen las vistas , los eventos, el controlador y, si se quiere así, los Busisness Delagates. El resultado es sorprendente: desaparece todo el código repetitivo y se entiende a la perfección.
Tengo que decir que, por ahora, es la opción que más me atrae, sobre todo, por su simplicidad.
Sin embargo, también tengo algunas dudas: la documentación es escasa (pero es que… es tan sencillo!), me preocupa la continuidad del proyecto y su nivel de aceptación, y aún queda ver como se comporta en aplicaciones grandes y modulares. En resumen, la apuesta es arriesgada.
Otro aspecto no resuelto, por el momento, es el tema de los mock objects, pero seguro que hay alguna solución si se estudia detenidamente[3]
Algunos enlaces relacionados son:
Otros recursos en Internet
Ahora toca estudiar en detalle los tres finalistas y hacer algunos ensayos con diferentes casos de uso para ver quién es el digno sucesor de Cairngorm.
Mientras tanto si tienes experiencia con alguno de ellos, te agradecería un comentario con tus impresiones.
- Utilizando Universal Mind Cairngorm Extensions se solucionan parcialmente este y otros problemas de Cairngorm
- Esta es una conversación interesante sobre la necesidad de usar un framework en Flex: http://flexblog.faratasystems.com/?p=280
- En este artículo se describe una alternativa: http://soenkerohde.com/2008/10/conditional-compilation-to-mock-with-swiz/
Entradas (RSS)
Thanks! Nice post.
Excelente Post !!! estoy poniendome las pilas con el Swiz estuve toda la tarde tratando de que entrara en mi cabeza toda la info porque es con la primera microarquitectura que me meto … dentro de todo esta bastante intuitiva, pero no he encontrado mas que lo de la pagina oficial de googlecode, lo que vos posteaste y alguna que otra cosa
0 diagramas de flujo
0 texto español
pero todo el mundo opina lo mismo: MUCHO FUTURO
Se ve muy bien Swiz, lo que no se es como implementar un proyecto completo, digamos con comunicacion con weborb, alguien sabe esto?
Gracias por el resumen, los no Flexeros te lo agradecemos como referencia : )
Sólo decir que la semana pasada en el LFPUG estuvieron los chicos de PowerFlasher y FDT:
http://www.lfpug.com/27th-november-2008-27112008/
Además de la charla de FDT dieron otra sobre modelos de desarrollo y ellos utilizan Parsley intensivamente (tienen unos 25 Flasheros en nómina haciendo aplicaciones). Yo no había oido nada y no tenía mala pinta, como dices tú también.
Un saludo!
Juan
Muy buen articulo
Desde hoy en adelante te visitare mas amenudo. Volviendo al tema de los framework, quiero destacar que apesar
de que cairngorm es un poco complicade este a sido mi heroe en todos mis proyecto. No se porque, pero siempre
que uso cairngorm el proyecto avanza, a medidas que le agrego mas funcionalidades, sin ningun problema de rediseño.
Es como magia, es una arquitectura en la que practicamente simpre funcionara (aunque complicada para pequeños proyectos)
pero nunca falla con respecto a MVC. Por otro lado, lo que mas me gusta es que puedes escojer a 100 desarrolladores de Flex,
y apuesto que de esos 100, 90 o mas ya sabran cairngorm, lo que agiliza el tiempo de entrenamiento. Pero, despues de todo,
lo que tu dices tambien es cierto, no es necesario usar un cañon para matar a un mosquito.
suerte
Excelente !!!!!!
No te das una idea la guia que ha sido tu informe !!!!!!
Este pequeño “estudio” de framework me ha llegado en el momento justo. Utilizo habitualmente Flex., pero siempre he desarrollado mini aplicaciones web con Flex en mis proyectos.
En estos momentos estoy empezando a desarrollar mi primer gran aplicacion en Flex., la cual sera integramente en Flex., y por lo tanto seguramente sera conveniente utilizar Modulos y algún framework.
No tengo conocimiento previo de ninguno de ellos ., pero tu informe es mas que orientativo., para alguien que se encuentra en el momento de tomar una decisión de cual utilizar.
Por lo que pude observar en base a vuestras recomendaciones., fui directamente a Mate y a Swiz., para ver que me ofrecían.
A simple vista ., lo que veo como un impedimento a utilizarlos., o tal vez., es que ninguno tiene una versión estable para produccion.
Mate 0.8.5
Swiz 0.0.3
Lo cual asusta un poco a un programador Flex novato como Yo.
Estan estos Frameworks aptos para comenzar a desarrollar un proyecto que terminará en producción ?
Estoy muy entusiasmado con la idea de utilizar Swiz., pero la doc es prácticamente nula., el foro casi no recibe posts., etc., parece ser que es muy nuevo., y no se cuando serán las proximas versiones.
Con Mate me paso lo mismo., pero la sensación es dif., la doc es bastante completa y el foro tiene su movimiento.
Es Mate semejante a Swiz ?
Es Mate dinamico en la liberacion de nuevas versiones ?
Muchas Gracias por tu informe
y espero con ansiedad me puedas orientar., dado que estoy “frenado”, “parado” ., esperando decidirme a comenzar a utilizar algún Framework., y comenzar con dicha Aplicacion Web en Flex.
Un dato mas….
En mis paginas Flex me comunicaba con HTTPService y paginas JSP devolviendo XML., deseo utilizar BlazeDS porque dicen es mas “profesional”., es recomendable su utilización ?
Muchas Gracias nuevamente.
Dios te Bendiga
Pablo Dario Ingelhorn
Argentina
Interesante, pero
¿No habrá un “framework” capaz de ahorrarnos escribir Código en lo absoluto?, lo digo pq ya hace mas de 10 años existió un producto llamado Magic, de Magic Software Enterprises, donde no empleabas NADA de código y todo lo hacías visual (Modelado, Pantallas, Logica) incluso lo vi ganando (al producto) la competencia RAD en los EU allá por el 96, hoy ese producto ha evolucionado y se llama uniPaaS y es sorprendente la facilidad con la que elaboras una aplicacion de cualquier tipo sin escribir código.
El otro día probé Flex y quise hacer un ejemplo de visor de mis fotos del disco duro con algún efecto … todo el día y no pude hacerlo !!! Y no porque no supiera OOP sino pq nunca me encontré con funciones como Directory() que me dieran el directorio así de simple sin tanta declaración e imports, así que para hacer una aplicación de escritorio quizá sea aun mas fácil hacerla con cualquier otro lenguaje que con Flex, y en esos detalles tan simples es como desaniman a cualquier futuro programador interesado en la tecnología Flex. El proyecto de Adobe no es malo, solo falta hacer ese “puente” para que ahora si “cualquiera” pueda desarrollar en Flex.
Yo creo que lo que tu planteas en este articulo ya esta obsoleto, la gente de universal mind creao un nuevo enfoque de cairngorm incluyendo la nueva posibilidad de controlar el flujo de los datos colocando tus propios callbacks, de esta manera pudieras, por ejemplo, recibir los datos de una vez dentro de la vista y asi no tener que pasar a traves del model. Aqui te dejo una muy buena explicacion de lo que te digo:
http://developyourdream.blogspot.com/2009/06/cairngorm-universal-mind-extension.html
Para Alejandro:
No creo que esté obsoleto. Las Universal Mind Extensions ya existían cuando lo escribí. Resuleven algunos de los problemas de Cairngorm, pero no todos.
En concreto son muy útiles cuando necesitas añadir callbacks en los comandos, como dices, pero sobre todo para encadenar comandos. Sin embargo, quien mas, quien menos, todos habíamos ya extendido Cairngorm para implementar ambas cosas.
El problema que tiene CUME es que son complicadas de aplicar y de explicar a otros programadores.
En este momento yo ya no utilizo ni Cairngorm ni ningún otro framework. He creado uno partiendo de ideas de Cairngorm, Swiz y Spring y estoy bastante satisfecho con él. Los programadores lo entienden y los usan sin problemas y el código se ha reducido y clarificado notáblemente.