A cada dia, vemos inúmeras aplicações com interfaces avançadas e cada vez mais sofisticadas surgindo no
mercado. Com o crescimento desse tipo de aplicação, que atende pelo nome de
Rich Internet Application ou aplicações de internet ricas(RIA), surgem novas
necessidades, tecnologias para
construção e também novos desafios. 

Esse desafio ocorre pelo fato de não estarmos trabalhando da maneira
tradicional, e passando a expor ao lado do cliente recursos ricos e
sofisticados para inúmeros fins. O Silverlight,
da Microsoft, vem ganhando espaço e tem
evoluído muito ultimamente. A intenção é disputar o mercado com as tecnologias
concorrentes como Flash e o Flex. 

Como
amamos arquitetura, onde ela se encaixa em um cenário desse? E o
desenvolvimento em camadas? São perguntas que iremos responder neste artigo.

Cenário Tradicionar X Cenário RIA

O que temos, no cenário
tradicional, é um campo em que o número de requisições ao servidor é grande.
A cada ação do usuário, seja uma pesquisa, uma alteração ou uma inserção de dados, é
realizada uma interação com o servidor. Esse fluxo contínuo de requisição e
resposta é inerente a esse tipo de cenário, pois ele está preparadao para
isso.

Já no cenário RIA, o fato de expor recursos ricos, avançados e uma
interface além de rica funcional como uma interface de um programa desktop, nos
leva a ter que tomar determinados cuidados, como evitar o excesso de requisições
ao servidor para evitar gargalo e perda de performance. São cuidados como
esses que temos que ter na hora de montar uma arquitetura, para um sistema que
roda em um cenário RIA.

RIA e os seus desafios

Um problema comum ao
se desenvolver aplicações RIA e até mesmo um dos seus desafios era justamente
desenvolver em camadas. Observe a imagen abaixo:

A imagem acima
ilustra um cenário web tradicional. Podemos observar que tanto a lógica da apresentação como
a lógica da aplicação ficam no servidor, sendo de responsabilidade da lógica da
apresentação renderizar o resultado requisitado pelo cliente – que
interage com a mesma através de inúmeras requisições, que devem ser
evitadas em um cenário RIA. Observe a próxima figura:

Na figura acima,
observamos o que diferencia um cenário RIA de um cenário tradicional, e vemos
que a lógica da apresentação não está mais do lado do servidor junto com a
lógica da aplicação, e sim do lado cliente. Isso se deve ao fato de garantir
a performance e evitar gargalos no sistema. Essa inversão é feita justamente
para manter o ambiente estável e evitar sérios problemas.

O WCF RIA Services

O WCF RIA Services é
um middleware de comunicação, ou seja, ele irá fazer a ponte entre a lógica da
aplicação (no lado do servidor) e a lógica da apresentação (no lado cliente), agindo como uma fronteira de confiança onde as camadas de
apresentação e de aplicação poderão se comunicar e trabalhar.

O WCF RIA Services visa facilitar e tornar mais suave o desenvolvimento em camadas para aplicações RIA. Para
isso, ele expõe serviços, operações e entidades para serem consumidos no lado do
cliente. Para entender melhor, observe a figura abaixo:

A
figura acima ilustra bem como o WCF RIA
Services funciona. No lado esquerdo, está o browser, responsável pela lógica da apresentação e pela fronteira de
confiança, ou seja, uma interface, um proxy em que a lógica da aplicação é
exportada através deste contrato. E atrás, no servidor, ficam as nossas bases
de dados, comunicação com outros serviços e até o domínio da nossa aplicação.

Domain Services X Domain Context

Os Domain Services funcionam como o coração do WCF RIA
Services. É ele quem controla a serialização de objetos para ambos os lados
servidor e cliente. Só precisamos escrever nosso código uma única vez e este fica disponível para os dois projetos em nossa solução: o projeto
servidor e Cliente. O Domain Context é onde o cliente
trabalha, ou seja, ele é um espelho perfeito do Domain Service, que roda no
lado do servidor. Analise a figura abaixo:

No projeto servidor fica
o Domain Service, que contém as entidades, as operações e os serviços com os quais
nossa aplicação trabalha. Já no projeto cliente, onde se encontra a solução
silverlight, fica o Domain Context – espelhando as operações, os serviços e
as entidades contidas no Domains Service.

Para um entendimento maior, vamos
analisar o projeto HRApp disponível no codeplex disponível para download.

 Em uma mesma solução, estão os projetos servidor (ASP.NET) e client (Silverlight). Veja
abaixo a descrição desse projeto de exemplo.

• Seta Azul: Indica o
  projeto silvelight, que é o projeto client

• Seta amarela: Indica o projeto ASP.NET, que é o projeto servidor
• Seta
  Vermelha: Indica o arquivo que é
  gerado automaticamente pelo WCF RIA Services. Esse arquivo é gerado da
  exportação das funcionalidades do EDMX, que é o modelo de dados e as funcionalidades
  que podem ser adicionadas. Ou seja, ele é o resultado da exportação do Domain Service. Uma vez sendo compilada a solução, se você abrir a pasta GeneratedCode
  dentro da mesma, estará um arquivo deste(extensão .g.cs).
• Seta
  Verde: Indica um EDMX, arquivo do
  entity Framework, que contém o modelo de entidades, que também tem suas
  funcionalidades exportadas para o arquivo que é gerado pelo WCF RIA Services.

Entendendo melhor o processo: quando
você compila o projeto, é feita uma cópia para o projeto silverlight do seu
Domain Service, ou seja, automaticamente o mesmo é espelhado no Domain Context – que contém absolutamente tudo que existe no Domain Service,
desde operações a entidades.

Abaixo, confira um trecho do
código do Domain Service e do Domain Context:

1. Domain Service

02.   Domain Context

As figuras acima
mostram o que foi dito: o Domain Context reflete justamente o
Domain Services. Então, pode-se trabalhar utilizando essa classe de proxy e
navegar, chamar e utilizar todas funções e serviços disponívels no Domain
Services.

Bom, pessoal, espero ter ajudado e ter passado um pouco do WCF RIA Services
e como ele pode ser extremamente útil no desenvolvimento em camadas para aplicações RIA.

Abraços e até a próxima!