separação da camada intermediária física para Windows Forms aplicativos

Question

Eu tenho projetado completamente alguns aplicativos do Windows Forms ultimamente (aplicativos de entrada de dados, integração de escritório, etc), e embora eu sempre projetado com camadas lógicas em mente, a camada de lógica de negócios "camada intermediária" tem sempre foi hospedado na área de trabalho PC (ou seja física cliente-servidor).

Ao me aproximar aplicações mais complexas, encontro-me ansiando por uma camada intermediária física em vez disso, com o cliente de desktop passando solicitações de volta a um servidor de aplicativos a lógica de negócios processo (que pode mudar regularmente) e interfaces. Parece que eu estou perdendo a fatores como escalabilidade e facilidade de manutenção que são mais nativos para aplicativos da Web.

Estou curioso para saber o quão longe os desenvolvedores outros WinForms tomaram sua separação de camada intermediária:

• Quanto processamento (se houver) que você executar em um servidor de camada intermediária?
• O método de comunicação que você está usando? - WCF, comunicação remota, serviços web, etc
• Quanto é o desempenho de um fator, e quantas vezes você ida e volta para o servidor?

Existe são um benefício em mover a lógica de negócios em uma camada separada, ou é mais prático para componentes do host localmente em um PC (e apenas certifique-se você tem um bom modelo de implantação para empurrar para fora lançamentos regulares como a mudança de regras de negócios) ?

Como alternativa, eu deveria ser orientar os clientes longe de WinForms completamente se esses fatores estão envolvidos? Com alternativas como o Silverlight e até mesmo ASP.NET w / AJAX, as razões para escolher um cliente WinForms parecem estar encolhendo.

Answer 1

O que é importante manter em mente é que há um trade-off entre a facilidade de desenvolvimento com uma camada intermediária separado vs todos os benefícios de escalabilidade etc. O que quero dizer com isto é que você tem que atualizar interface de mapeamentos etc no seu código, você tem que implantar um lugar camada intermediária para seus testadores de usar, que precisa ser atualizada etc. Além disso, se você é preguiçoso como eu e passar o seu Entity Framework objetos ao redor diretamente, você não pode publicando-os para uma camada intermediária , para que então precisa criar DTO para todas as suas operações, etc.

Alguns essa sobrecarga pode ser tratado por um sistema de compilação decente, mas que também precisa de esforço para configurar e manter.

Minha tática preferida é manter separação física em termos de montagens (ou seja, eu tenho um acesso a lógica de negócio separado / dados de montagem) e para encaminhar todas as chamadas para a camada de negócios através de uma camada de interface, que é um monte de fachada Aulas. Então, todos estes conjuntos residem dentro do meu aplicativo do Windows. Eu também criar interfaces de para todas estas fachadas, e acessá-los através de uma fábrica.

Dessa forma, eu nunca deveria precisar a separação de uma camada intermediária, eo trade-off em termos de produtividade é vale a pena, eu posso separar a minha camada de negócios para fora, colocá-lo atrás de um serviço WCF (como que é o meu preferido plataforma de serviços) e executar algumas refatorações em termos do que meus fachadas mão para fora, eo que eles fazem com o que eles aceitam.

Answer 2

Este é um exemplo de por que eu tendem a fazer sempre o trabalho em um ambiente web. Se a rede está disponível para seu aplicativo cliente para chamadas de serviço, é certamente disponível para enviar e recuperar dados de um servidor web.

Certamente, as restrições de cliente pode alterar o seu percurso final, mas quando dada a oportunidade de influenciar a direção, eu orientar para soluções baseadas na web. Existem tecnologias de implantação disponíveis que lhe dão um caminho de atualização mais fácil do que um pacote de desktop tradicional, mas não há nenhum substituto real para atualizar um aplicativo baseado em servidor.

Answer 3

Dependendo da sua aplicação, existem vários problemas de desempenho para manter em mente.

Se o seu trabalho é muito semelhante entre vários clientes (dados compartilhados), em seguida, fazendo o processamento em uma camada intermediária é melhor, porque você pode fazer uso de cache para reduzir o processamento geral.

Se o seu é diferente entre clientes (dados privados), então você não vai ter grande lucro, fazendo o processamento em uma camada intermediária.