n-Tier Architecture feedback necessário

Question

Eu comecei o meu site, como stackoverflow, com um pouco de dívida técnica que eu estou tentando pagar. Sendo um desenvolvedor de contrato, eu estive em muitos lugares e ver muitos métodos diferentes de alcançar este resultado, mas a maneira que eu vou é ..

Apresentação (web)

Layer Negócios (aulas antiquados entidade e camada BL)

Camada de Dados (aulas da AD para SQL Server via Proc)

A minha pergunta diz respeito principalmente a camada de negócios. Agora eu tenho um espaço de nomes de entidades e um namespace BusinessLogic.

O BL tem uma referência para o promotor e da Entidade. A entidade tem uma referência para a DA (A DA é "inconsciente" do BL ou entidade)

Eu realmente quero toda a minha agitação de transformar dados em entidades de ocorrer dentro do BL - portanto, a lógica de negócios. No entanto, quero a entidade a ser capaz de acessar a BL se necessário -. E, assim, retirar a referência da Entidade com o DL

Então ...

Será que é "errado" para que o BL e objetos de entidade dentro do mesmo namespace para que possam trabalhar juntos?

Essencialmente, estou tentando ter um objeto de entidade como empregado (exemplo clássico, né?) E ter o empregado ter um

public Hashtable[] SubordinateEmployees

propriedade que retorna uma tabela de hash de outro funcionário objetos que o relatório a esse empregado. Mas eu não quero carregá-lo até que seja necessário. Assim, para a maioria dos funcionários da propriedade nunca seria acessada, mas quando isso acontecer, ele auto-cargas com uma chamada para o BL, que chama a DA.

Será que o sentido questão make?

Se sim, faz a minha solução?

Muito obrigado antecipadamente!

Answer 1

A maneira usual de lidar com o tipo de situação o seu exemplo representa é com fachadas. Em vez de tentar obter os funcionários subordinados do objeto Employee, você usa uma chamada para a lógica de negócios para obtê-lo.

hashtable = BL.GetSubordinateEmployees(supervisor);

Dessa forma, você tem um único ponto de acesso para os subordinados, e há apenas uma coisa (a BL) acessando a camada de dados e criação de entidades.

Answer 2

Deixe-me ver se eu posso mostrar-lhe a melhor maneira de pensar sobre isso

você tem o seu acesso de dados (SQL Server, MySQL, arquivos xml planas, etc.) tudo isso deve ser abstraída mais nada em sua aplicação deve cuidar ou saber como você está recebendo seus dados, apenas que a dose, se qualquer outra coisa sabe que você está recebendo os dados que você tem uma violação camada. se a dose nada DAL outro em seguida, obter dados que você tem uma violação camada. Em seguida, você implementar uma interface de acesso a dados algo como IDAL que seus usos camada de negócios, isso é muito importante para fazer a sua testável código, forçando-o a separar suas camadas.

As suas entidades de dados podem ser colocados no espaço de nome DAL ou dar-lhes lá próprio, dando-lhes há forças próprias separação. entidades de dados são objetos mudos e deve conter muito pouca ou nenhuma lógica e só são conscientes de si e os dados que eles têm, eles não contêm BUSINESS LOGIC !, dados de acesso LOCIC, OU UI LOGIC. se você tem uma violação camada. A única função de uma entidade de dados é para armazenar dados e ser passado de uma camada para a próxima.

Biz implementos camada uma interface de acesso a dados como o IDAL falamos antes você pode instanciar isso com uma fábrica, um recipiente IOC, ou todos não um tipo de concreto mais, mas adicionar uma propriedade setter de modo que este pode ser alterado para o teste. A camada Biz Só lida com lógica de negócios, não saber ou se importar onde os dados vieram ou para onde está indo, ele só se preocupa com a manipulação dos dados para cumprir com as regras de negócios, o que inclui validação de data, filtrando (parte disto é dizendo a DAL que dados de que necessita, deixe a figura DAL fora como obtê-lo). Basicamente as alças BIZ toda a lógica que não é UI relacionados ou recuperação de dados relacionados. Assim como o DAL a Biz deve implementar uma interface, pela mesma razão.

A camada de interface do usuário acessa a camada Biz da mesma forma a camada Biz acessa o DAL pela mesma razão. Todos os cuidados a camada UI sobre está exibindo dados e obter dados do usuário. A camada de IU não deve saber nada sobre as regras de negócio, com a possível exceção de validação de dados necessários para preencher as entidades de dados.

A vantagem desta arquitetura é que obriga separação de conceitos facilitando o teste, mais flexível e mais fácil de manter. Hoje você está construindo um site, mas amanhã você quer permitir que outros a integrar vi um serviço web, tudo que você tem a fazer é criar um serviço web que implementa a interface IBiz e seu feito, quando você tem que corrigir um bug no BIZ camada, já está fixo em ambos os seu site e serviço web.

Tomar este para o próximo nível, digamos que você está fazendo um monte de número pesada trituração e você precisa de servidores mais poderosos para lidar com isso para que tudo que você tem a fazer é implementar uma interface Idal e IBiz que são realmente wrappers para WCF que lida com a comunicação entre os servidores, agora o aplicativo é distribuído entre vários servidores e você não tem que alterar seu código para fazê-lo.