Cairngorm – Parte 4

Essa é a parte 4 do artigo (que contém exemplos práticos, baseados no Cairngorn Store). Este é referente a microarquitetura Service to Worker, que envolve os design patterns Front Controller, Event Broadcaster e Command, que em conjunto integram-se com o Model Locator e o Value Object. O original em inglês está disponível aqui.

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