Separar a lógica de negócios dependente de referências da web fora da camada de apresentação

Question

Tenho um aplicativo da web com uma camada de apresentação e uma camada de negócios como projetos individuais. Um sendo um aplicativo da web e o outro sendo uma biblioteca de classes. Eu adicionei uma referência da web ao aplicativo da web para usar um serviço da web. Não estou tendo problemas para usar a API de serviço, mas estou me descobrindo adicionando muita lógica de tipo de camada de negócios em minha camada de apresentação para utilizar esta API. Eu adoraria se pudesse apenas alterar parte do código da minha camada de negócios para trabalhar com o serviço da web, mas a configuração de tal parece uma grande circular, não, não. De qualquer forma, eu adoraria que meus objetos continuassem fazendo o que estão fazendo, mas também funcionassem com um serviço da web, mas me encontro tendo que criar uma classe auxiliar / gerente na minha camada de apresentação para trabalhar com a web -serviço. Isso me faz exigir alterações de código em todos os lugares em que estava executando as ações nos objetos que queria adicionar com o serviço. Qual é a maneira correta de atacar esse problema?

Não tenho certeza se há uma pergunta legítima em qualquer parte dessa divagação, mas se alguém pudesse oferecer alguma palavra útil, eu ficaria muito grato.

Obrigado !!

Answer 1

A maneira como abordei isso é criar algo com este efeito:

• Camada de acesso a dados
• Camada de lógica de negócios

• Camada de serviço (desprovida de qualquer lógica de negócios, apenas uma interface)

  ---

• Camada de acesso ao serviço (sem qualquer lógica de negócios ou lógica de apresentação)

• Camada de apresentação (MVC, Presentation Logic, etc ...)

Sua camada de serviço, sendo desprovida de lógica de negócios, agora pode ser alterada sem afetar sua lógica de negócios.Sua camada de acesso ao serviço no lado do cliente protege você de mudanças na interface do serviço também.

Answer 2

Se sua camada de serviço expõe apenas métodos semelhantes a serviços (como, talvez, métodos CRUD simples como SaveInvoice (InvoiceDTO)), então, na maioria dos casos, você deve estar bem. No entanto, podemos usar algum código do seu lado.

Existem muitas maneiras de construir camadas de serviço, com estado, sem estado, etc. etc., então tente explicar a repetição que você obtém em sua apresentação

Answer 3

Talvez você deva fazer com que seu serviço encapsule a lógica de negócios também?Dessa forma, sua camada de apresentação acessaria apenas o serviço - o serviço acessaria a camada de lógica de negócios.