Enfim, o ponto é que a Adobe disponibilizou um treinamento do Cairngorm que é parte integrando do treinamento oficial. É um documento sucinto, com pouco mais de 40 páginas. Acredito que ele não deva ser utilizado como única fonte de informação sobre o assunto, mas é uma excelente introdução explicando inclusive oo propósito do Cairngorm (e não apenas sua codificação, como ocorre em outros tutoriais/artigos/etc).

Leia mais no post “Introducing Cairngorm” no site da Adobe.

Achei fantástica a iniciativa de complementar o documento! Se ele concorda com o que está ali, não há necessidade de criar algo completamente novo simplesmente para chamar de seu. Esse é um modelo, aliás, pelo qual outros documentos e artigos poderiam evoluir naturalmente.

Bem, ainda não li o documento que ele disponibilizou por inteiro, mas ele é basicamente o que está disponível no site da DClick com três tópicos novos: Adobe Cairngorm, E4X Guidelines e Regular Expressions.

Particularmente, embora eu acho interessante ter um “Cairngorm Coding Guidelines”, eu não acho que este deva estar dentro de um “Flex Coding Guidelines”. Fazendo assim, presume-se que o Cairngorm deve ser utilizado sempre que se utilizar o Flex, e isso não é todo verdade. Aliás, nenhum framework é tão perfeito e abrangente que resolve todos os problemas. Frameworks resolvem problemas específicos, então só os use se você tiver os problemas que ele visa resolver. Ou ainda, como diz o Beck, não se deve achar que um framwork sozinho é a solução, e sim que ele é apenas um ponto de partida.

Nessa linha, há um antigo post do Steven Webster que continua válido: Why I think you shouldn’t use Cairngorm. Pensei que já havia publicado esse link auqi no CFGigolô, mas não o achei. De qualquer modo, a leitura é bem interessante, principalmente para os iniciantes em desenvolvimento.

Por favor, não me levem ao extremo: eu acho o Cairngorm fantástico e recomendo a todos os desenvolvedores que dêem uma olhada nele pois ele já se provou muito eficiente e tive ótimas experiências com ele.

E a estrutura para entender o MVC, uma vez que ele é um padrão de arquitetura (alguns o chamam de framework, de paradigma, etc.. mas acredito que chamá-lo de arquitetural seja mais significativo) é o mesmo do entendimento de um design pattern: entender o problema (que é a motivação para o surgimento de um padrão), entender o padrão, e por fim entender como o padrão resolve o nosso problema.

A partir do momento que o software começa a ficar grande e complexo demais e que muitos dados são apresentados para o usuário, sentimos a necessidade de separar os dados (model) da interface (a view), de modo que as mudanças na UI não mudem o modo como gerenciamos os dados. E isso é feito desacoplando (removendo a relação direta) da user interface do acesso aos dados através de um elemento adicional, o controller, que irá intermediar essa relação.

Assim, a responsabilidade de cada um dos três elementos fica bem definida:

O Model representa as informações do domínio do aplicativo (a Folha de Pagamento, por ex) e fornece funções para operar os dados (calcular o total da Folha, por ex.), isto é, ele que expõe as funcionalidade do aplicativo. O Model também é responsável por notificar a View quando os dados forem alterados.

A View, objetivamente, deve renderizar o Model e possibilitar a interação do usuário, bem como consultar ao Model quando este notificá-la de que houve alterações nos dados afim de manter a consistência entre ambos.

O Controller, o maestro da orquestra, responde às ações dos usuários (um clique, por exemplo), possibilita mudanças no Model (fazer uma requisição ao servidor e obter novos dados, por exemplo) e seleciona a View correspondente.

E deste modo, desacoplando a View do Model e com a separação de responsabilidade, reduz-se consideravelmente o nível de complexidade do software, permitindo também uma maior especialização e foco do desenvolvedor, algo de extrema importância hoje em dia com a necessidade cada vez maior de interfaces com o usuários mais efetivas.

Esse fluxo pode ser sintetizado conforme a imagem abaixo, cujo original é da Sun:

Um ponto importante aqui é não confundir o MVC com desenvolvimento em Três Camadas. Desenvolvimento em Três Camadas é uma arquitetura para softwares cliente-servidor, e as camadas representam sistemas distintos (camada de apresentação, camada de negócios e camada de dados, que podem, análoga e respectivamente, ser um aplicativo em Flex, o código Java no servidor e um banco de dados). E fundamentalmente a camada de apresentação nunca pode acessar os dados diretamente, isto é, deve passar pela camada intermediária (ou pelas camadas, já que há sistemas com mais de três camadas).

E embora MVC e Três Camadas pareçam significar a mesma coisa, o nível em que eles atuam é bem diferente. Enquanto o MVC trata do código do aplicativo propriamente dito, o desenvolvimento em Três Camadas refere-se a um nível topologicamente mais alto (entre os sistemas). Outra diferença vital é que em Três Camadas o fluxo é linear (da camada de apresentação para a de negócios, de negócios para dados, voltando de dados para negócios e de negócios para dados), em MVC é triangular (a View envia um comando para o Controller, que por sua vez atualiza o Model e a View é consulta os novos dados no Model). Portanto, não vamos confundir as coisas!

E as implementações em MVC variam de acordo com a linguagem, claro. Mas nada disso é realmente novo, e há algo mais que gostaria de apresentar aqui, agora que já estamos contextualizados.

Eu e Beck Novaes, quando trabalhávamos juntos em um projeto educacional e de treinamento em desenvolvimento em Adobe Flex e Cairngorm, criamos uma série de idéias e conceitos, dos quais uma delas era relacionada à MVC.

Você provavelmente já escutou a história dos Três Macacos Sábios, não é mesmo? Muito possivelmente associada a Gandhi, que sempre levava consigo os três totens dos macaquinhos. Um os macacos está tampando os olhos, outro tampando os ouvidos e o terceiro tampando a boca, representando “não veja o mal, não ouça o mal, não fale o mal”.

Da mesma forma, apresento os Macacos MVC (ou MVC Monkeys para os gringos…):

• A View é muda, mas faz gestos (user gestures) para o Controller e escuta mudanças no Model;
• O Model é cego, mas escuta o Controller e fala para a View sobre as mudanças nele próprio;
• O Controller é surdo, fala para o Model quando mudar de estado e vê os gestos da View.

Novamente, reitero que é interessante ler o artigo original de Steven Webster na íntegra para um melhor entendimento. Essas sínteses apresentadas aqui no blog são apenas como referência e fazem parte de um estudo que conduzi com minha equipe atual. E nem estes devem ser considerados únicas fontes de informação de arquiteturas de aplicação – aspecto vital para um bom produto final.

Cairngorm Architecture Review
1. Front Controller espera User Gesture
- Um User Gesture (clique, dragging, etc) disparam eventos no Cairngorm
- EventBroadcast divulga o acontecemento do evento
- FrontController está escutando por eventos, gerenciando “quem faz o quê”
2. Commands realizam o trabalho
- FrontController manda para o Command correspondente realizar o trabalho
3. Delega lógica de negócio do servidor para o Business Delegate
- Frequentemente o Command requer que o servidor realiza uma tarefa
- Command não quer saber como, apenas que seja feito
- Commands delegam a responsabilidade da lógico de negócio server-side para outra classe
4. Localizar o serviço com o Service Locator
- O Business Delegate provê uma interface entre o Command e qualquer serviço no servidor
- Para o Delegate, não importa com o que está conectando-se
- O detalhe da implementação dessse serviço está encapsulado no Service Locator
- Service Locator é um diretório de serviços que a aplicação poderá utilizar
- Resultado pode voltar para o onReult() ou o onFault() do Command que originou a chamada
5. Transferir dados como Value Objects
- Encapsular dados como VO que descrevem o que estes são dados em termos de negócio ao invés de termos técnicos
6. Guardar estado no Model Locator e notificar a View
- Model Locator armazena o estado da aplicação
- Views possuem bindings (ligações) com o Model, de modo que atualizações no Model notificam a View para atualizar a interface com o usuário e refletir os novos dados

Cairngorm Flow of Control
1. Nova funcionalidade na aplicação
- Registrar o evento e o Command no Front Controller
- Implementar um novo Command, com o execute() para realizar o trabalho, onResult() para gerenciar o resultado, atualizando o Model Locator
- Adicionar novas chamadas a serviço necessárias no Business Delegate, que o novo Command por ventura faça uso
- Se um novo serviço for necessário, cria-lo no Service Locator
2. VOs
- Criar VOs caso estes sejam necessários para passar dados do Command para o Business Delegate, e deste para o servidor, ou guardar no Model Locator
- VOs possivelmente já existirão na aplicação e serão reutilizados
3. Debugging
- Verifique se o evento está registrado no Front Controller
- Verifique se o execute() é chamado no Command pelo Controller
- Verifique se o método apropriado do delegate está sendo chamado
- Verifique se o onResult() do Command é chamado
- Verifique se o estado é atualizado no Model Locator

In Perspective
1. Entender os benefícios de construir uma RIA com a microarquitetura Cairngorm
2. Benefícios demonstrados quando a aplicação cresce em termos de funcionalidades
3. Decompor requerimentos de negócio em tarefas técnicas implementadas com o Cairngorm, ajudando a estimar custos e esforços
4. Com o Cairngorm, desenvolvedores mais fácilmente podem tornar-se generalistas, aptos a implementar recursos através de toda a aplicação 5. Generalização (ao invés da especialização) significa melhor aproveitamento do skill da equipe, entre outros benefícios.
6. Cairngorm não é o único modo de construir RIAs. Os conceitos podem ser utilizados de diferentes modos para resolver os problemas no desenvolvimento.

Novamente, recomendo que o artigo original seja lido na íntegra para um melhor aproveitamento. Esse conjunto de posts é referente a um estudo realizado e não deve ser considerado única fonte de referência no assunto.

Integrating with Flex RPC Services
1. Desafio: qual funcionalidade deve ser executada no cliente e qual deve ser executada no servidor.
- Impactos em performance, escalabilidade, segurança e experiência
2. RIA resolve, integrando com o servidor de forma uniforme
- Usuários não percebe o que é processado no servidor ou no cliente
3. Mecanismos de integrar com dados server-side: Flex Remote Procedure Call (RPC) Services
- HTTPService: XML ou strings simples
- WebService: SOAP
- RemoteObject: AMF, tradução de objetos do Java e do CF para AS.
4. Muitos usos para um serviço e diferentes serviços
- Cairngorm implementa dois patterns para esse gerenciamento

Locating Services with the Service Locator
1. ServiceLocator é um repositório de todos os serviços que a RIA precisará
- Centralizar e reutilizar os serviços
2. Abstrai do desenvolvedor qual o tipo de serviço
- Independe se é Java, WebService ou HTTP
- Trata-os da mesma maneira
- Encapsula os detalhes da implementação dos serviços
3. Best practices
- Named services: não expor ao cliente detalhes da implementação de conexão, por segurança
- Sempre implementar um result e fault handler direcionando para quem os chamou
4. Command poderia chamar diretamente o ServiceLocator, mas Cairngorm sugere mais uma camada de abstração

Proxying Services with the Business Delegate
1. Um serviço (ou método getProducts(), por exemplo) pode ser chamado em diferentes lugares da aplicação
- De modo que o resultado dessa chamada seja tratado de maneiras diferentes, dependendo do contexto que o serviço foi chamado
- Ou seja, o Command é por Use Case, e diferentes Commands podem chamar o mesmo método no servidor, mas realizando tarefas distintas nos handlers de result e fault.
2. Delegar a responsabilidade de lógica de negócio de localizar o servico e invocar o método no servidor em uma classe separada
- Business Delegate
3. Funcionamento
- Command cria uma instância do Delegate, passando si próprio como construtor do Delegate
- Desse modo, Delegate têm para quem passar o resultado, um “Responder”
- Agindo como o Responder, o Command implementa a interface Responder
- Métodos onResult() e onFault()
4. Ponto de interface entre o cliente e o servidor
- Separar a equipe responsável por implementações server-side e client-side.

Um dos maiores paradigmas desse estilo de desenvolvimento está nesse trecho do artigo: “No more scattering of business logic across an ever-growing ecosystem of MXML components. No more monolithic classes that state ‘if the application just did this, then do that; but if it did this, then do the next thing…’”

Engaging in Rich Conversations
1. Rich
- Descreve uma melhor user experience do que a apresentada por aplicativos web tradicionais
- Riqueza na interatividade: comunicação rica entre usuário e aplicativo
2. Cairngorm
- Utiliza uma colaboração de design patterns que a comunidade J2EE costuma utilizar para gerenciar a comunicação entre homem e máquina

The Service to Worker Microarchitecture
1. Front Controller
2. Event Broadcaster
3. Command

Service to Worker: Mapping User Gestures and System Occurrences to Events
1. Usuário executa features a partir de user gestures
- Usuário ordena produtos clicando em um botão
- Usuário filtra produtos ao arrastar o slider
- Usuário adiciona produtos em um carrinho por arrastar o produto até omesmo.
2. Desenvolvimento web tradicional
- Cada característica requer um request HTTP
- Processamento no servidor e refresh de página
3. Execução sem user gesture
- Pegar dados na inicialização da aplicação
4. Cairngorm trata “user gestures” e “system events” do mesmo modo: “Cairngorm Event”
- User request agora são eventos internos que componentes podem transmitir quando reconhecerem um user gesture ou um system event.

Service to Worker: Listening for Events with the Front Controller
1. Quando um user gesture indicar a execução de uma característica (executea feature), o Cairngorm requer o broadcast de um evento apropriado.
2. Executing a feature: Command Pattern
- Implementação em classes
- Método execute() para um terceiro chamar a classe sem precisar saber o queeste faz.
- Worker classes
3. Command Classes (exemplo)
- Interface Command obriga a ter um método execute(), que age como ponto de entrada: permite o Cairngorm executar o Command sem saber o que exatamente ele faz
- execute() recebe um objeto do tipo Event, uma classes do Cairngorm que descreve o tipo do evento e dados associados.
- Binding com o ModelLocator: user experience irá refletir as atualizações de acordo
4. Helper Classes
- Classes para retirar a lógica de negócios dos Commands
- Extract class refactoring
- Permite unit test
5. Controller
- Um conjunto de trabalhadores (workers) sem um responsável é muito ruim!
- Controller garante que workers façam sem trabalho quando requerido
- Ponto de entrada para todos os eventos no Cairngorm
- Best practice: todos os eventos como constantes
- Um broadcast errado de “addProduct” (como string) só será percebido como errado (e o certo era “addProductToCart” em tempo de execução. Utilizando variáveis constantes (ShopController.EVENT_ADD_PRODUCT) o erro será pego em tempo de compilação.

Service to Worker: Broadcasting Cairngorm Events with the Event Broadcaster
1. Peça final é dar o broadcast destes eventos
2. Singleton Event Broadcaster
3. Best Practice: métodos simples que descrevem o broadcast de um evento em termos de negócio.
4. Exemplo
- Componente ProductDetails expõe o evento addProduct, que contém o produto e a quantidade que o user gesture adicionou.
- Esse evento faz o broadcast para o FrontController utilizando o Event Broadcaster de uma constante (Controller.EVENT_ADD_PRODUCT_TO_CART)
- Cairngorm chama AddProductToCartCommand, atualizando o ModelLocator
- Integração do Service to Worker microarchitecture (Front Controller, Event Broadcaster e Command) com Model Locator e value Object

Os pontos mais interessante foram as best practices sugeridas, dentre elas uma que sempre sugeri: nomes semânticos para os elementos (componentes, telas e afins) – não me venha com nomes em código!; e a questão de disparar eventos, muito mais utilizado agora no Cairngorm 2 (e reformulado no Flex 2).

Architecting the View
1. User Experience deve:
- Representar o estado atual da aplicação
- Mostrar telas específicas
- Renderizar o model
2. Rich Internet Application
- Comunicação entre o usuário e a aplicação
- A melhor forma de comunicação é a bidirecional
- User Experience “fala” para o usuário renderizando a view de acordo com o estado
- User Experience “escuta” o que op usuário gostaria de fazer, e responde de acordo
- User gesture

Binding the Model to the View
1. Cairngorm garante que dados dinâmicos mostrados no MXML venham do ModelLocator, apenas.
2. Model notifica a View da mudança através do data-binding
- Desenvolvedor não precisa se preocupar em atualizar vários elementos para refletir mudança

Best Practices for MXML Development
1. Desenvolver pensando em componentes
- Fácil de criar componentes que extendem tags base
- Significado semântico (ex: detalhe do produto): facilidade de ler código, inclusive de outros
2. Acople os componentes mas não fixe-os
- Crie seus eventos que descrevam o que está ocorrendo no nível do usuário (não no nível do Flex)
- De “click=” para “ocorreu o evento productAdded”
- Clareza em pontos de integração

O original no qual esse estudo é baseado está disponível do Developer Center.

Cairngorm Store
1. Flex Store
- Aplicação de demonstração
2. airngorm Store
- Reconstruído utilizando o Cairngorm
- Rápido, escalável e de fácil manutenção

The Cairngorm Store: Four Key Challenges
1. Visões de um desenvolvimento de aplicação
- Como solução de problema de negócio
- Sistema que implementa a solução
- Arquitetura técnica para software customizado
- Nível detalhada de implementação das classes
2. Quatro desafios principais de alto nível
- Manter estado (state) no cliente
- Arquitetar a visualização
- Desenvolvimento baseado em requerimentos (FDD, modelo de desenvolvimento ágil)
- Invocar serviços de servidores

Keeping State on the Client
1. Em RIAs, o cliente mantém estados
- Web tradicional era request/response, com uso de cookies, sessão, etc.
2. MVC
- O cliente mantém os dados
- O state é o Model: objetos que têm significado
- Mapas: o object model contém ruas, rotas, referências, postos de gasolina, etc.
3. Sincronização
- Um estado no cliente normalmente reflete o estado em outra ponta (o servidor)
- No desenvolvimento de aplicações server-side, o estado está entre duas camadas: business e integration tier
- No desenvolvimento de aplicações enterprise, o sistema é apresentado através de um middle-tier (ou business tier): manter o estado entre as camadas
- Manter o estado é complicado pois a representação relacional em uma ponta (banco de dados, por exemplo) é diferente da outra, com objetos (Java, por ex).
- Problema de consistência: manter o mesmo dado em dois lugares
- Problemas de concurrency, lock, transactions, rollbacks, etc.
- Desenvolvimento RIA: model do business tier ser igual ao presentation tier
- Basta um Object model consistente!
4. Value Object ou Data Transfer Object Pattern
- Representar “coisas” e seus valores
- Estrutura intercambiável entre as camadas
- Transformação de dados de significados técnicos (RecordSets, ResultSets, Data Sets) em objetos com significados de negócio (pessoas, mapas, etc)
- Coleção de atributos que descreve uma entidade

Keeping a Consistent Object Model Between Flex and Java
1. Tradução automática entre VOs do Flex e do Java
2. XDoclet cria VOs em ActionScript baseados no Java
3. VOs permitem:
- Best practice em representar dados no cliente com significados do object model
- Manter consistência do object model no cliente e no servidor
- Utilizar a capacidade do Flex em traduzir VOs entre o Java e o ActionScript

Binding the Model and View Together
1. R do RIA: Apresentar dados de maneira rica e profunda
2. Databinding
- Mudanças na origem refletem no destino
- Dados e visualização, por exemplo
- Model e View
3. “Responsiveness” à mudanças no Model
4. Dificuldade em variáveis de dados intercambiáveis entre diferentes contextos da aplicação

Enter the Model Locator Pattern
1. Lugar único onde o state é guardado, e Views podem achar os dados
2. Uso do databinding
3. Variáveis estáticas, singleton

Essa é a primeira parte é de um conjunto de seis posts baseados nos artigos do Steven Webster no Flex Developer Center.

Procurando orientar a comunidade sobre as melhores práticas do uso do Cairngorm, Steven Webster escreveu um conjunto de seis artigos no Flex Developer Center sobre o Cairngorm, projeto do qual ele faz parte.

Esse post é referente à primeira parte do artigo, com os principais pontos traduzidos de forma livre, a fim de conduzir a equipe com quem trabalho hoje sobre as melhores práticas de desenvolvimento de RIAs.

Ou seja, aqui estão apenas alguns dos pontos que eu anotei como sendo importantes na hora de transmitir essa informação à equipe, de modo que a leitura completa dos artigos (bem mais completo do que as sínteses que irei apresentar) é bastante proveitosa.

Um dos pontos chaves dessa primeira parte é no final, em que ele discute que o Cairngorm não é a solução de todos os problemas, embora por experiência ele tem atendido muito bem.Frequentemente me perguntam qual o melhor framework para ColdFusion: Mach II, FuseBox, ModelGlue, Tartan, etc. Não há um melhor, claro, pois cada um deles pretende resolver problemas específicos de arquitetura, desenho e eventualmente de camadas.

Frameworks
1. Application Frameworks
- Class libraries
- Componentes
- Provê funcionalidades básicas, flexíveis e integráveis.
2. Architectural Frameworks
- Esqueleto de aplicação
- Estrutura arquitetônica para construir aplicações sobre.

Design Patterns
1. Pattern: Solução de engenharia para problema específico e recorrente.
- Exemplo: apenas uma instancia dessa classe (Singleton)
2. Pattern overload: cuidado com o excesso desvairado e abdicação extrema de responsabilidade.

Microarquitetura
1. Problema maior e mais genérico
- Intercepectar um user gesture e certificar que a classe responsável sssuma a responsabilidade
2. Microarquitetura = conjunto de design patterns
3. Cairngorm: architectural framework (óbvio)
- Desafios da contrução de RIas
- Ponto de partida para artquitetura de RIAs, visando resolver problemas frequentes anteriormente já resolvidos.

Cairngorm
1. iteration::two
2. Livro eality J2EE: Architecting for Macromedia Flash MX
3. Flex, com sua linguagem declarativa, possibilitou soluções mais elegantes que as apresentadas anteriormente

Ensinamentos do Cairngorm
1. Gerenciar user gestures no cliente
2. Encapsular lógicas de negócio (e interação com servidor)
3. Gerenciamento de estados da aplicação e sua representação na UI

Estágio atual do Cairngorm
1. Versão 0.99
2. Versão 2.0 em conjunto com Flex 2 (iteration::two agora é Adobe Consulting)
- Versão muito similar, mas aproveita novas funcionalidades.
3. Cairngorm *não* é a única maneira de construir RIAs em Flex
- Frameworks resolvem problemas. Que problemas você tem?

Uma versão interessante, com algumas novidades, principalmente na utilização do ModelLocator e no tratamento de eventos, não mais com o EventBroadcaster e sim sugerindo ao desenvolvedor que crie seus próprios eventos e os “dispare” utilizando o novo modelo de eventos do Flash (com dispatchEvent()).

A equipe responsável por esta nova versão pede o feedback da comunidade na lista FlexCoders.