Dúvida arquitetura WCF

Question

Pessoal,

 

Atualmente tenho uma aplicação dividida logicamente em camadas, ou seja, Camada de Apresentação(UI), Camada de Negocio(BLL) e Camada de Acesso a Dados(DAL), onde minha UI faz referencia às dlls da BLL que faz referencia à DAL, até ai tudo bem ...

 

Preciso distribuir essa aplicação em diferentes servidores, ou seja, minha UI em um servidor de aplicação e meus outros componentes em um outro servidor, estou implementando isso com o WCF, com isso minha camada de apresentação não poderá fazer referenciar a camada de negocio, ai que vem a pergunta ... o que será referenciado pela minha UI ? Se eu criar minhas Classes Modelos(Entities Class) essas poderão ser referenciadas pela minha UI mesmo em ambiente distribuido ? Qual é a real arquitetura para uma aplicação distribuida utilizando WCF ? Favor citar ás referencias que cadas camada deve realizar.

 

Muito Obrigado

Answer 1

Erik,

a camada UI deverá referenciar o serviço (através de um service locator e seu contrato) e data contracts, que representarão os dados que serão trafegados pelas camadas.

Portanto,

 

Server 1:

UI - Service Contract / Data Contract

 

Server 2:

Implementação do serviço de BLL e referência para a DALC. Se a DALC estiver em outro servidor, crie um outro serviço para isto.

 

Lembrando que utilizar o protocolo correto para comunicação entre as camadas é muito importante. Se você estiver em um ambiente que possibilite, mantenha protocolos TCP ou NamedPipe. HTTP traz um overhead um pouco grande para este tipo de finalidade.

 

Abraços

 

Answer 2

O ponto central de serviços, e isso inclui WebServices, WCF, Remoting ou até mesmo uma DLL, é ocultar algo do consumidor (encapsulamento), a priori.

Serviços tem a grande vantagem de fornecer este encapsulamento de forma desconectada.

O que isso significa?

Significa que você sequer precisa ter referências às DLLs das classes originais para consumir o serviço. E, se não temos DLL físicas, o que impede de acessar um serviço .Net em Java? A resposta é: nada... É possível e até fácil.

Então serviços entram como uma forma de encapsular o seu aplicativo, expondo certos métodos e dados ao mundo exterior DE FORMA MULTIPLATAFORMA.

Por este motivo, todos que usam serviços da forma correta tendem a ter a mentalidade da desconectividade. Isso quer dizer que você não precisa saber o que tem dentro da "caixinha", você precisa apenas utilizá-la.

Este é o objetivo dos contratos do WCF. Você fala o que quer exportar, tanto em questão de métodos quanto em questão de dados (e entende-se por dados dados primitivos (String, Int, etc.) ou dados complexos (classes)), mas, pelo sentido do serviço ser multiplataforma e isolacionista, não faz sentido algum passar suas classes complexas como DLLs/Referências.

Aí chegamos ao proxy: um código que é gerado pelo consumidor que, literalmente, imita a organização de seus métodos/classes passados pelo serviço e os utilizam, sem que, necessariamente, você precise das classes originais. Exatamente por isso posso pegar uma classe .Net, passar por um web service e utilizá-la em Java.

Tendo em mente isso, o melhor "approach" é desconectar: cada coisa tem que ficar no seu devido lugar, completamente isolado e ser tranportado entre camadas por um serviço. Desta forma, você nunca corre o risco de usar métodos de uma classe fora do contexto em que ela se aplica (ou seja, não corre o risco de salvar uma entidade diretamente para a base a partir da user interface).

As vantagens? Muitas...
DESDE QUE O CONTRATO NÃO SEJA QUEBRADO ENTRE AS CAMADAS, você pode simplesmente trocar a base de dados de Sql Server para Oracle, mudar todo o código da sua camada ou, que seja, até trocar a linguagem da sua camada com precisamente ZERO de impacto nas outras camadas.

Este é o sentido de serviços.

Answer 3

Nem todos os serviços são baseados em tecnologias multiplataforma padrões de mercado (WS, por exemplo), JCKödel. Logo, a forma com qual o serviço é construído, disponibilizado e acessado é importante para decidir por uma estratégia.

Erik, esta distribuição é um requisito? Qual o motivo desta escolha? Lembre-se que esta decisão impõe mudanças significativas no modelo de programação (granularidade das interfaces, Data Transfer Objects, Assemblers e etc).

[]s