Nas últimas semanas me foi pedido para elaborar uma prova de conceito que juntasse o melhor de vários mundos. Uma aplicação em Silverlight, base de dados SQL Server e uma arquitectura de 4 camadas (4-Tier).
A aplicação Silverlight não tinha muito que saber pois, é um género de agenda simples onde adicionamos, alteramos e apagamos contactos. Assim a aplicação contem 2 formulários: Lista de contactos e edição de contacto. Associados a estes formulários, forma programadas as três operações CRUD (Create, Update e Delete).
A dificuldade aqui era integrar a arquitectura nesta prova de conceito, pois, a implementação tradicional de RIA Services não permite que a lógica da aplicação esteja noutro servidor, mas, no mesmo que a aplicação Silverlight está a ser executada.
A complexidade da arquitectura deve-se ao facto termos que desagregar o User Interface (UI) da lógica de negócio (Business Layer) e ainda tornar indisponível servidor de base de dados para o User Interface como demostra o gráfico em baixo:
Assim, para suportar esta arquitectura o que fiz foi :
- desenvolver uma aplicação Silverlight que usa RIA Service como Wrapper do serviço que está no Servidor Aplicacional. Esta solução torna que seja possível fazer um "push" dos objectos de negócio para a aplicação Silverlight sem que seja necessário criar projectos de partilha de recursos.
- Desenvolver um componente RIA Service no servidor Web que possiblita a invocação dos métodos que desejamos
Como podemos ver, temos três métodos no RIA Service que poderão ser usados pela aplicação Silverlight. Como este RIA Service não tem acesso à base de dados, não implementa o LinqToEntitiesDomainService, mas, DomainService. Desta forma para invocar estes métodos temos que fazer na aplicação Silverlight o seguinte:
Todos os acessos a RIA Services são efectuados assincronamente, pelo que necessitamos de definir o evento Complete para a operação. Neste caso o evento de Complete refresca a lista de contactos.
Por fim, o RIA Service deve conectar-se ao serviço WCF que está no servidor aplicacional dentro da zona de servidores protegida. O componente WCF no servidor aplicacional pode ser um serviço windows ou uma console application que vai estar à escuta na porta 4534 (podia ser qualquer uma, eu escolhi esta).
- Por último desenvolve-se o serviço WCF no servidor aplicacional que vai estar à escuta na porta 4534 por solicitações. Configurei para que esta comunicação seja NetTcp para garantir privacidade e performance.
Este serviço WCF efectua operações na base de dados (operações CRUD) e usa EF4 como ferramenta de ORM.
Foi assim garantida assim a segurança dos dados de ataques indesejados.
Paulo Aboim Pinto
Odivelas - Portugal
1 comment:
Olá, boa tarde. O meu nome é João Amaral e sou estudante universitário, encontrando-me a estudar Eng. Informática na UBI. Há alguns tempos encontrei esta comunidade de blogs quando resolvi aprender Silverlight e C# para um projecto de bases de dados, e depois de muito esforço consegui fazer uma interface gráfica para uma aplicação cujo objectivo seria a implementação numa oficina. A última fase do projecto será estabelecer a comunicação entre a base de dados e a aplicação, mas como na universidade nunca aprendi C# e tomei a iniciativa de aprender sozinho, e o professor não dá apoio na parte da aplicação, tenho tido dificuldades em conseguir estabelecer a ligação. Na Internet já li posts sobre utilizar a framework COM, utilizadar ADO services e RIA services.. tudo me parece muito confuso, e gostaria que alguém, com experiência, me indicasse o melhor caminho a seguir. Tentei pesquisar o seu endereço de email mas sem sucesso, por isso decidi fazer este comentário "privado" neste post. Se pudesse entrar em contacto comigo através do email a21430@ubi.pt, ficaria-lhe imensamente agradecido. Muito obrigado desde já pelo tempo despendido a ler este pedido de ajuda.
Com os melhores cumprimentos,
João Amaral
Post a Comment