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
Leave a comment