Cairngorm – Parte 2

Na seqüência do primeiro artigo, essa segunda parte discute os desafios do desenvolvimento das RIAs, e foca no primeiro deles: manter o estado no cliente, e discute a solução desses problemas com os patterns VO (ou DTO, Data Transfer Object) e ModelLocator.

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