Cairngorm III:Commands

Tal como comentamos en los artículos anteriores una aplicación RIA potencia el desarrollo orientado a prestaciones (featured oriented development) es por ello que aparece la necesidad de poder aislar y reutilizar todas las funcionalidades de los aplicativos que diseñemos. Minimizando las prestaciones y funcionalidades individuales potenciamos la reutilización. Mejor tener muchos elementos especializados que pocos y muy poco especializados, esta es otra de las bases de la microarquitectura de Cairngorm.

Un patrón command es la solución implementacional a la ejecución de una funcionalidad concreta requerida. Los comandos también son transversales y pueden ser invocados desde cualquier capa. Evidentemente existirán comandos especializados en las distintas capas. La transversalidad es posible gracias a que son stateless, es decir son totalmente ortogonales e independientes al entorno y circunstacias de invocación. Simplemente tienen acceso a los datos que requieren en todo momento para poder ser ejecutados.

Los commands son la parte más importante de nuestras apliaciones ya que en ellos reside la lógica (business logic) de nuestra aplicación. En primera instancia en los Commands no se tiene en cuenta la capa visual ni cómo se van a ejecutar. Un Command sólo es responsable de saber qué hacer cuando alguien o algo lo ejecute.

Por la su propia naturaleza, los commands se pueden anidar (siguiendo un patrón Composite) dando como resultado un MacroCommand, que sería la creación de un command a partir de otros más simples pero encadenando su ejecución, dando como resultado un comando conceptualmente más amplio e implementacionalmente hablando más complejo. En Cairngorm esto se consigue a traves de lo que han llamado SequenceCommand.

Los commands aislan totalmente la funcionalidad de tal forma que el que los ejecute los puede ver como cajas negras que aportan funcionalidad.

Veamos ejemplos conceptuales de distintos commands:

• Dada una url lanzarla como link en un nuevo navegador (similar a lo que haría un link de html con el parámetro target seteado a _blank.
• Dada una clase que herede de UIComponent lanzar una instancia en un PopUp integrado en nuestro aplicativo utiliznado PopUpManager.
• Ejecutar un método concreto de un servicio SOAP y recoger los resultados.
• Consumir los datos XML de una url y recoger los resultados.
• En una aplicación que use en algun punto navegación por tabs, crear un nuevo Tab.
• etc.

En el plano implementacional, un Command tiene que ser una clase (por convenio en el package commands) que implemente la interface com.adobe.cairngorm.commands.Command Esta interface sólo implica que en la clase exista un método execute con la firma execute (event:CairngormEvent):void

En breve veremos qué es event, para qué nos sirve y de dónde sale. Antes de eso veamos un ejemplo de un command.

Este primer comando lo único que hará en el momento de ejecutarse es presentar por pantalla un caja de Alerta con un texto determinado. Tal como iremos viendo la complejidad de los commands oscilará mucho dependiendo de la complejidad de nuestra aplicación. Pero por norma general y teniendo en cuenta que es una de las bases de la microarquitectura de Cairngorm, los Commands serán clases relativamente cortas. En contra partida podemos llegar a tener muchos Commands (del orden de cientos en grandes aplicaciones).

Para ejecutar este Command lo podríamos llegar a hacer de una forma muy sencilla:

Lo único que hemos hecho es instanciar la clase HelloWorldCommand y ejectuar el método execute.

Aunque esta forma de ejecución funciona correctamente y seguramente es la más tradicional, podríamos decir que no es la más óptima ni la que más beneficios nos aporta, no es la que Cairngorm fomenta.

Por definición los Commands son la unidad mínima funcional de nuestra aplicación, son stateless (entre distintas ejecuciones no guardan el estado) y a nivel conceptual deberían poderse ejecutar desde cualquier lugar de nuestra aplicación. Un Command debe encapsular su lógica interna y debe ser intercambiable por otro command sin ninguna repercusión a nivel implementacional (obviamente sí a nivel funcional).

Viendo que todos los commands se ejecutan de la misma forma (llamando al método execute), Cairngorm implementa una solución para la invocación basada en el patrón FrontController.

Fte: http://www.madeinflex.com/2006/10/21/cairngorm-iii-commands/