O Cairngorm é o carro chefe dos frameworks para a plataforma Flex. Há quem diga que é o framework que todo desenvolvedor flex deve conhecer. E de fato o é. Ele é simples e intuitivo, e é também suportado pela Adobe. Por todos esses motivos é o mais utilizado no mercado. Bom é que ele não é o único.

Dentre os frameworks para a plataforma Flex em desenvolvimento atualmente, um deles vem se tornando cada vez mais popular. Me refiro ao PureMVC, visto ter sido citado como “vencedor” em uma comparação de frameworks (ao todo, 9) para o Flex e desde então só tem aumentado seu número de interessados.

Antes de iniciar a exposição do framework em questão, em linhas gerais, é necessário entender o que é um Framework de Aplicação. Assisti a exposição citada logo acima e achei-a clara, precisa e útil no que concerne a definição de um Application Framework. Recomendo a visão desta apresentação com atenção mais precisa a esta parte. Reproduzo agora em um parágrafo a síntese do que assimilei para que não percamos o desenrolar do raciocínio.

Um Application Framework(Servidor de Aplicação) pode ser dividido em duas metades. A parte Prática e a parte Metodológica. A parte prática pode ser definida como as classes e padrões que irão compo-lo. A parte Metodológica é a parte do como fazer, como usar. Esta parte, muitas vezes chamada de boas práticas, pode ser entendida como a ideologia de utilização dos patterns de um determinado framework. É a vontade constante de manter tudo desacoplado e coeso. É aquilo que nos baseamos na hora de decidir se é melhor criar um Command para executar determinada função ou disparar um evento para um Manager definido no Model que executará uma função específica de uma View. Enfim, a junção destas duas metades é chamada de Application Framework. Capiche?

O PureMVC:

Model
View
Controller
Façade
Mediator
Command
Proxy
Notification
Observer

Diferenças primariamente percebidas entre o PureMVC e o Cairngorm:

A estrutura meta-padronizada Model-View-Controller do PureMVC é pouco similar ao Cairngorm. Diferentemente deste, nós não desenvolvemos classes do tipo Model, View, ou Controller. Estas classes já estão implementadas no PureMVC de maneira que ficam essencialmente “escondidas”. Utilizamos o MVC implementando Mediators, Commands e Proxys. Estes são registrados nas classes Singleton: View, Controller e Model respectivamente. Trocando em miúdos, Mediator = View, Command = Controller e Proxy = Model.

O registro nas Entidades principais citadas logo acima acontece da seguinte forma. As classes Model, View e Controller são instanciadas como Singleton dentro da Classe Facade, de maneira que o Facade, que também é Singleton, disponibiliza métodos que tem a função de registrar um Mediator na View, um Command no Controller e um Proxy no Model, tudo por composição. Uma vez instanciado o Facade, a estrutura MVC já está criada e pronta para uso. Sim, o PureMVC é lindo. Brincadeiras a parte, imagino que se tudo está claro até agora, é fácil concluir que todo o trabalho de implementação de uma aplicação desenvolvida com o PureMVC vai ser feita dentro de Mediators, Views e Commands.

Ok, mas como esses “caras” se comunicam??

Diferentemente do Cairngorm que usa uma estrutura de eventos (CairngormEvent) o PureMVC utiliza o padrão Notification. Uma notificação pode ser disparada de um Mediator, por exemplo, e ser “escutada” em um ou mais Commands e vice versa. A estrutura do padrão Notification, isto é, a forma como, por exemplo, um Mediator pode escutar uma notificação de um Proxy, está implementada internamente no framework, através do padrão Observer, ficando longe da visão do desenvolvedor. Apesar do PureMVC ser mais complexo e com uma curva de aprendizado maior do que a curva de aprendizado do Cairngorm a estrutura do padrão Notification, isto é, a forma como um Mediator pode escutar uma notificação de um Proxy por exemplo, está implementada internamente no framework ficando longe da visão do desenvolvedor. Isto faz o nosso framework em questão ser simples de implementar mas sem perder a robustez.

Após esta exposição superficial, é possível concluir que, por agrupar mais patterns que o Cairngorm, o PureMVC é mais complexo. Apesar da complexidade ficar “escondida” do desenvolvedor, é claro que é necessário, num primeiro momento, entende-la. Desta forma, a curva de aprendizado se torna maior. É melhor que o Cairngorm? Pode ser. Acredito que este framework irá dar bons frutos em projetos grandes no futuro, mas assim como o Cairngorm, o PureMVC é um Application Framework e por esse motivo sofre dos males que todos os Applications Frameworks sofrem: Se não utilizado com uma METODOLOGIA bem definida, isto é, com a vontade constante de manter tudo coeso e desacoplado, pode abrir espaço para problemas de implementação.