Dependency Injection em uma aplicação n-tier?

Question

Eu tenho um aplicativo de serviço .NET 3-tier, que segue a abordagem padrão:

Frontend -> Object Model / Business Logic -> Data Access

Eu estou tentando aprender sobre injeção de dependência ao longo do caminho, e, até agora, têm encontrado grande (usando Autofac). Cada um dos 3 níveis precisa para criar uma variedade de objetos, às vezes com configuração extra / etc. Parece que o recipiente DI deve ser a coisa ideal para resolver isso, mas eu estou tendo alguns problemas de ver onde ele deve viver em relação com o resto do sistema.

Atualmente tenho uma classe no frontend que configura o contêiner DI. É basicamente um grande monte de código dizendo container.Register<SomeType>() e assim por diante.

O problema é, que é a configuração do recipiente para todos os 3 níveis, e, portanto, deve ter conhecimento relativamente invasiva da camada de acesso a dados. Tendo código no meu frontend com tais conjuntos de conhecimento fora sinos de alarme na minha cabeça como o ponto de separar o aplicativo em camadas é para evitar essa situação exata.
Isso também é agravada pelo fato de que a minha camada de acesso a dados não é servidor apenas SQL sendo um balde mudo de bits, mas é feita por lotes de interoperabilidade COM complexo e chamadas P / Invoke, por isso tem um grande impacto sobre o DI configuração.

Eu dei algum pensamento para quebrá-lo - talvez tendo um contêiner por camadas, ou ter uma aula de "Setup" em cada camada que fala com o recipiente DI global para registrá-lo é possuir pedaços, mas eu não tenho certeza se que irá causar mais problemas do que resolve ...

Eu realmente aprecio isso se alguém poderia compartilhar suas experiências no uso de DI com aplicativos de vários níveis.

Obrigado, Orion.

Answer 1

Isso depende se você tem tem três níveis (separação física) ou se todas as suas camadas lógicas são implantados juntos. Se o frontend é separado do BL e comunica através de um webservice ou WCF, então o frontend eo backend precisa de seus próprios recipientes, porque eles estão correndo em processos separados ou máquinas separadas. Os recipientes só iria registrar seus próprios componentes e as interfaces do 'próximo' camada.

Por outro lado, se todas as camadas estão em execução no mesmo processo, então você deve ter apenas um recipiente. O recipiente será inicializado e hospedado no ponto de aplicação como global.asax para um aplicativo web começando.

O problema com o anfitrião recipiente saber a muito de todas as diferentes partes do sistema poderia ser resolvido por não registrar as classes um por um, mas em vez registrar todos os tipos em uma montagem. Dessa forma, você não precisa de fortes referências a todos os conjuntos em sua solução apenas para configurar o contêiner. Exemplo de como isso pode ser feito com Castelo Winsdor:

Kernel.Register(AllTypes.Pick().FromAssemblyName("DataAccessLayer.dll"));
Kernel.Register(AllTypes.Pick().FromAssemblyName("BusinessLogic.dll"));