Melhor maneira de fazer referência a objetos de negócios da camada de apresentação ..?

Question

Quero desenvolver um aplicativo corporativo que inclua uma camada de apresentação do WindowsForms, componentes de nível médio para lógica de negócios e acesso a dados e um banco de dados do MSSQL Server. Os componentes de camada média devem conter alguns objetos de negócios e serão chamados da camada de apresentação usando o .NET Remoting. Witch é a melhor maneira (e por que) fazer referência a esses objetos de negócios da camada de apresentação?

• A) Criar projeto de biblioteca de classes, implementando objetos de negócios. Faça referência a este projeto da camada de apresentação e da camada de camada média.
• B) Crie projetos de biblioteca de interface Definindo objetos de negócios. Crie interfaces de criação de projeto de biblioteca de classes. Projeto de biblioteca da classe de referência da camada de camada média. Projeto de biblioteca de interface de referência da camada de apresentação.
• C) Crie projetos de biblioteca de classes separados para camada de nível médio e apresentação. Projeto correspondente de referência da camada de apresentação.

Answer 1

Provavelmente não há uma resposta clara e definitiva para isso, depende do que você está fazendo.

• UMA muitas vezes será bom o suficiente em muitos casos. Para pequenos projetos de 'aplicativo único', não há realmente nenhuma razão para você não pode simplesmente fazer referência à biblioteca de objetos de negócios diretamente das camadas da interface do usuário e do BL. É certamente a melhor e às vezes a simplicidade é a melhor.

• B É provavelmente o "melhor", você estará abstraindo suas implementações reais para que as mudanças futuras sejam possíveis sem quebrar contratos, e o teste de unidade é mais fácil se você tiver interfaces. A outra vantagem disso é que você não achará muito difícil mudar de B para C no futuro, se achar necessário.

• C provavelmente é um exagero na maioria dos casos. Dito isto, em projetos maiores, você pode achar necessário. Eu trabalhei em grandes aplicativos de camada N cliente-servidor que tiveram até três conjuntos independentes de objetos de dados. Um conjunto usado na camada DA para mapear e armazenar no banco de dados. Um segundo conjunto na lógica de negócios e nas camadas de rede para processar e passar pela rede e o terceiro conjunto no cliente para ligação à interface do usuário. Vale a pena considerar o uso de interfaces para C também por causa das vantagens de abstração.

Em suma, sem saber exatamente o domínio ou o escopo do seu aplicativo - B é um bom ponto de partida.

Answer 2

Eu já vi todas as três abordagens funcionarem bem.

O que às vezes pode ser bom é começar com A, então à medida que a complexidade aumenta para B, então C.

Em projetos simples, os "objetos de negócios" podem ser incluídos no mesmo projeto que as camadas de apresentação e persistência - embora possa parecer heresia, definir os objetos usando diferentes namespaces pode fornecer separação suficiente entre as "camadas".

Você pode querer reconsiderar o uso do .NET remoto - o WCF é de longe uma tecnologia melhor e muito mais fácil de usar.