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