none
Dúvida arquitetura WCF RRS feed

  • Pergunta

  • 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

    quinta-feira, 19 de junho de 2008 12:26

Respostas

  • 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

     

    segunda-feira, 23 de junho de 2008 17:17
  • 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.
    sábado, 19 de julho de 2008 03:53

  • 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
    terça-feira, 22 de julho de 2008 23:29

Todas as Respostas

  • 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

     

    segunda-feira, 23 de junho de 2008 17:17
  • 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.
    sábado, 19 de julho de 2008 03:53

  • 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
    terça-feira, 22 de julho de 2008 23:29