none
Dúvidas na arquitetura. O que é o ideal? RRS feed

  • Pergunta

  • Boa tarde a todos.
    Fiz uma aplicação onde cada camada é representada por um projeto.
    Interface, Negócios e Dados.

    Hoje, ao instalar a versão Client da aplicação, nada mais é que a versão server com um app.config apontando para outro lugar (banco de dados em outra máquina), porém quero mudar isso.

    Estou estudando (comecei hoje) sobre WCF e gostaria de dicas de vocês.

    Pelo que entendi até agora, vou ter a camada de interface que acessará outro projeto como um serviceclient. Este serviceClient conhece o servidor e dispara a requisição no Serviceserver que por sua vez deve saber aonde estão a camada de negócio e dados e dar continuidade ao processo, devolvendo os dados solicitados ou executando no banco os dados.

    É isso mesmo??

    Se for, surgiu outra dúvida:

    Para cada classe minha, tenho um Set e Get diferente no banco.
    Se eu tenho uma Entidade Cliente, no projeto de Regras de Negócio existe um ClienteRules e na camada de dados existe um ClienteDAL.

    A tela disparava um ClienteRules.Save ou ClienteRules.Load, que por sua vez disparava um ClienteDal.Save ou ClienteDal.Load.

    Agora, pelo jeito preciso ter uma ICliente por exemplo, que fica entre a tela e o clienterules. Só que vou ter essa interface e depois ter que registrar todas as interfaces existentes no serviço? Isso seriam muitas. É isso mesmo??

    att
    Leandro
    segunda-feira, 21 de setembro de 2009 16:37

Respostas

  • Boas Leandro,

    O WCF permite você efetuar a comunicação entre as partes. As regras de negócios e a forma que você acessa ou salva os registros, continua sendo a mesma. A diferença é que quando você faz o Load ou o Save no cliente, o que você estará fazendo é a comunicação com o serviço correspondente.

    Já com relação as classes suas que, parece que representa os registros (Get/Set), elas podem ser trafegadas entre o cliente e o serviço. E sim, para cada serviço, você tem que ter uma interface correspondente. Talvez você não precise ter uma ICliente, IProduto, IPedido, etc., você poderia refinar, fazendo algo como IData, e dentro dele métodos como RecuperarPedidos, AdicionarProduto, RecuperarClientes, etc. O dificil desta técnica, é ter uma boa coerência.
    http://www.israelaece.com
    segunda-feira, 21 de setembro de 2009 17:45
    Moderador
  • Boas Leandro,

    Sim, para cada contrato você deve registrar um endpoint específico. Mas lembre-se de que interfaces são "herdáveis", ou seja, você pode criar uma interface, ir herdando e herdando e depoos expor somente a interface mais completa.

    Com relação aos serviços em si, eu acho que se você para fazer serviços CRUD, seria mais simples recorrer ao ADO.NET Data Services: http://www.israelaece.com/post/Servicos-CRUD.aspx.
    http://www.israelaece.com
    segunda-feira, 21 de setembro de 2009 19:10
    Moderador
  • Boas Leandro,

    Eu penso que deve existir dois tipos de serviços: aqueles que entregam dados para a sua aplicação e aqueles que expoem regras de negócios.

    Como eu disse, esses serviços que entregam dados, você poderia fazer uso do ADO.NET Data Services, que muitas vezes são apenas CRUD. A partir do momento que possui processos complexos, tarefas a serem executadas, etc., você cria os serviços WCF para isso. Os serviços irão expor coisas como IGestorDeCredito, IFinanciamentos, etc., ou seja, as regras em si.
    http://www.israelaece.com
    terça-feira, 22 de setembro de 2009 11:16
    Moderador

Todas as Respostas

  • Boas Leandro,

    O WCF permite você efetuar a comunicação entre as partes. As regras de negócios e a forma que você acessa ou salva os registros, continua sendo a mesma. A diferença é que quando você faz o Load ou o Save no cliente, o que você estará fazendo é a comunicação com o serviço correspondente.

    Já com relação as classes suas que, parece que representa os registros (Get/Set), elas podem ser trafegadas entre o cliente e o serviço. E sim, para cada serviço, você tem que ter uma interface correspondente. Talvez você não precise ter uma ICliente, IProduto, IPedido, etc., você poderia refinar, fazendo algo como IData, e dentro dele métodos como RecuperarPedidos, AdicionarProduto, RecuperarClientes, etc. O dificil desta técnica, é ter uma boa coerência.
    http://www.israelaece.com
    segunda-feira, 21 de setembro de 2009 17:45
    Moderador
  • Israel, é o CAOS na terra, o apocalipse, o julgamento final NÃOO!! :|

    :P Desculpe o drama, talvez aqui não é o local ideal mas as vezes tenho uma recaída de gibis hehe

    Eu estou direto no seu site agora, se fosse um TCC sobre WCF a referência bibliográfica seria seu site! :)
    Parabéns pelo material.

    Eu tive medo de fazer dessa forma, mas acho o ideal. Um serviço para cada um. Depois vou precisar registrar um por um la no hosting... isso mesmo, certo?

    Seria dessa forma que você faria?

    Pq se for pensar como windows service, você não teria um serviço para cada objeto. Você precisa ter um serviço só, por isso o termo "service" me deixou um pouco confuso!


    segunda-feira, 21 de setembro de 2009 18:47
  • Boas Leandro,

    Sim, para cada contrato você deve registrar um endpoint específico. Mas lembre-se de que interfaces são "herdáveis", ou seja, você pode criar uma interface, ir herdando e herdando e depoos expor somente a interface mais completa.

    Com relação aos serviços em si, eu acho que se você para fazer serviços CRUD, seria mais simples recorrer ao ADO.NET Data Services: http://www.israelaece.com/post/Servicos-CRUD.aspx.
    http://www.israelaece.com
    segunda-feira, 21 de setembro de 2009 19:10
    Moderador
  • Essa foi a parte que não entendi LHUFAS da conversa Israel! :|

    Acho que não seria legal dessa forma, seria?? Fazer um só com a interface mais completa?

    Como você faria neste caso? Um pra cada?

    Eu estou fazendo isso tudo Israel, com o propósito de permitir o acesso a minha aplicação via internet.
    Eu entendi da forma certa tudo isso? É a forma mais inteligente pro que eu preciso?

    Como eu citei ali em cima, anteriormente era só fazer minha tela chamar a regra de negócio, que chamava a camada de dados, criava o que era preciso e retornava o objeto (ou entidade, não sei o nome certo, mas a classe Cliente por exemplo) populada de forma correta e jogava denovo na tela.

    Tudo o que queria, era uma forma (a melhor visando o futuro longiquo que for preciso) para fazer isso permitindo acessos pela internet.

    Você acha que eu estou no caminho certo?

    Obrigado por tudo

    att
    Leandro


    segunda-feira, 21 de setembro de 2009 19:31
  • Boas Leandro,

    Eu penso que deve existir dois tipos de serviços: aqueles que entregam dados para a sua aplicação e aqueles que expoem regras de negócios.

    Como eu disse, esses serviços que entregam dados, você poderia fazer uso do ADO.NET Data Services, que muitas vezes são apenas CRUD. A partir do momento que possui processos complexos, tarefas a serem executadas, etc., você cria os serviços WCF para isso. Os serviços irão expor coisas como IGestorDeCredito, IFinanciamentos, etc., ou seja, as regras em si.
    http://www.israelaece.com
    terça-feira, 22 de setembro de 2009 11:16
    Moderador
  • Obrigado Israel,

    vou prosseguir no meu raciocínio. Acho que estava certo desde o início, mas muito incrédulo resolvi perguntar.

    Abraços
    terça-feira, 22 de setembro de 2009 11:26