Pergunta

Temos um aplicativo que, juntamente com muitas coisas, faz algumas alterações no Active Directory (adicione/remova o usuário do grupo, altere os valores do atributo no usuário etc.).

Agora estamos no processo de redesenhar (de "código de espaguete" em uma solução mais em camadas). As funções de gerenciamento do Active Directory são algo que gostaríamos de abstrair até certo ponto na camada de domínio, mas, ao mesmo tempo, a maioria das funções depende muito de tecnologia.

Devemos colocar todo o código de acesso do Active Directory na camada de acesso a dados junto com o nosso acesso ao banco de dados, ou é bom criar uma biblioteca de funções do Active Directory e chamar essa biblioteca diretamente do modelo de domínio? Isso faz com que o objeto de domínio persista consciente e provavelmente é uma má idéia?

Ou todo o acesso do Active Directory deve ser executado na camada de serviço e nem mesmo envolver a camada de domínio?

Foi útil?

Solução

Os modelos de domínio devem ser tecnologia-agnóstico, então não coloque seu código de anúncio no modelo de domínio.

Em essência, você poderia dizer que o código do anúncio é apenas mais uma forma de acesso a dados, por isso pertence ao acesso aos dados Camada (Dal). No entanto, não pertence ao seu módulo de banco de dados, pois isso seria uma violação do Princípio de responsabilidade única (SRP - Aplica -se a módulos e tipos individuais).

Em vez de agrupá -lo com o acesso ao banco de dados, implemente -o em sua própria biblioteca. Conceitualmente, ele pertence à mesma camada, mas faz coisas diferentes, então agora você tem duas bibliotecas na mesma camada. Isso é absolutamente bom - você pode ter quantas bibliotecas em cada camada necessário.

No modelo de domínio, trate o acesso a anúncios (e o acesso a dB) como abstrações. Abstrato Repositórios são a abordagem padrão. A biblioteca de anúncios conterá implementações do repositório de anúncios e a biblioteca do banco de dados conterá implementações dos repositórios do banco de dados.

Isso se encaixa bem com Design orientado a domínio e o conceito de um Camada anticorrupção.

Você pode usar Injeção de dependência (DI) Para conectar os repositórios de concreto com seu modelo de domínio.

Outras dicas

Eu acho que as coisas específicas da tecnologia são detalhes de implementação, não devem ser colocadas no modelo de domínio.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top