Cairngorm – Parte 5

Dando seqüência à quarta parte, esta quinta e penúltima discute as implementações do Service Locator e do Business Delegate. Um dos principais pontos é que cada Command é de um use case, e ainda assim pode chamar o mesmo método no servidor, o que justifica o delegate (veja mais sobre as responsabilidade de cada pattern do Cairngorm nesse post. Também é comentado sobre o desenvolvedor responsável pela integração com o server-side e o desenvolvedor do cliente.

Novamente, recomendo que o artigo original seja lido na íntegra para um melhor aproveitamento. Esse conjunto de posts é referente a um estudo realizado e não deve ser considerado única fonte de referência no assunto.

Integrating with Flex RPC Services
1. Desafio: qual funcionalidade deve ser executada no cliente e qual deve ser executada no servidor.
– Impactos em performance, escalabilidade, segurança e experiência
2. RIA resolve, integrando com o servidor de forma uniforme
– Usuários não percebe o que é processado no servidor ou no cliente
3. Mecanismos de integrar com dados server-side: Flex Remote Procedure Call (RPC) Services
– HTTPService: XML ou strings simples
– WebService: SOAP
– RemoteObject: AMF, tradução de objetos do Java e do CF para AS.
4. Muitos usos para um serviço e diferentes serviços
– Cairngorm implementa dois patterns para esse gerenciamento

Locating Services with the Service Locator
1. ServiceLocator é um repositório de todos os serviços que a RIA precisará
– Centralizar e reutilizar os serviços
2. Abstrai do desenvolvedor qual o tipo de serviço
– Independe se é Java, WebService ou HTTP
– Trata-os da mesma maneira
– Encapsula os detalhes da implementação dos serviços
3. Best practices
– Named services: não expor ao cliente detalhes da implementação de conexão, por segurança
– Sempre implementar um result e fault handler direcionando para quem os chamou
4. Command poderia chamar diretamente o ServiceLocator, mas Cairngorm sugere mais uma camada de abstração

Proxying Services with the Business Delegate
1. Um serviço (ou método getProducts(), por exemplo) pode ser chamado em diferentes lugares da aplicação
– De modo que o resultado dessa chamada seja tratado de maneiras diferentes, dependendo do contexto que o serviço foi chamado
– Ou seja, o Command é por Use Case, e diferentes Commands podem chamar o mesmo método no servidor, mas realizando tarefas distintas nos handlers de result e fault.
2. Delegar a responsabilidade de lógica de negócio de localizar o servico e invocar o método no servidor em uma classe separada
– Business Delegate
3. Funcionamento
– Command cria uma instância do Delegate, passando si próprio como construtor do Delegate
– Desse modo, Delegate têm para quem passar o resultado, um “Responder”
– Agindo como o Responder, o Command implementa a interface Responder
– Métodos onResult() e onFault()
4. Ponto de interface entre o cliente e o servidor
– Separar a equipe responsável por implementações server-side e client-side.