Cairngorm – Parte 6

Essa é a sexta e última parte (parte 1, parte 2, parte 3, parte 4 e parte 5) do conjunto de artigos sobre o Cairngorm. Essa última parte apresenta um resumo sobre o funcionamento da microatquitetura proposta, bem como um interessante exemplo de implementação de uma nova funcionalidade no Cairngorm Store (o Flex Store convertido para o Cairngorm).

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.