Onde devo fazer a injeção com Ninject 2+ (e como faço para organizar meus módulos?)

Eu tenho uma solução com dois projetos relevantes (para esta pergunta) e alguns outros;

  1. Biblioteca de classs com funcionalidade usada por vários outros projetos.
  2. Aplicativo ASP.NET MVC.

A minha pergunta é basicamente onde eu deveria fazer o IoC com o Ninject 2, considerando …

  • A biblioteca de classs precisa de algum amor de DI, entre outras coisas nas classs de repositorys que precisam de objects de session específicos de solicitação da web (pense em Unit of Work).
  • O aplicativo MVC precisa de DI já que com o Ninject 2 você basicamente herda de NinjectHttpApplication.
  • Testes de unidade para a biblioteca de classs precisam estar cientes disso para injetar um conjunto diferente de repositorys.
  • Testes de unidade para o aplicativo da Web precisam ser injetados pelo mesmo motivo.

Eu me pintei em um canto mental aqui, porque eu só vi três opções para começar. DI na biblioteca de classs, DI no aplicativo da web ou ambos, mas há problemas com cada um:

  • Eu não posso fazer DI apenas na biblioteca de classs desde que o aplicativo MVC precisa herdar de NinjectHttpApplication para começar.
  • Eu não posso fazer DI apenas no aplicativo MVC – a biblioteca de classs é usada por outras bibliotecas, afinal de contas, e o aplicativo MVC não deve saber muito sobre os componentes internos da biblioteca de qualquer maneira.
  • Eu acho que esta é a única saída que eu posso ver: Independent IoC para ambos os projetos. A biblioteca de classs e o aplicativo MVC têm sua própria configuração de IoC e fazem DI por suas coisas sem realmente se importar um com o outro.

Alguém tem algumas “melhores práticas” ou orientações sobre como fazer algo assim? Eu não posso imaginar que sou a primeira pessoa a acabar nesta situação, e com certeza seria bom saber qual é a maneira “correta” de fazer isso …

Obrigado!

    Eu não conheço o NInject, mas a menos que funcione muito diferente de Windsor, StructureMap etc., as respostas tendem a permanecer as mesmas, pois existem alguns padrões de DI comuns. Com aquilo em mente:

    A primeira coisa a perceber é que o DI não está vinculado a um framework específico, como o NInject ou o Windsor. É um conjunto de técnicas e padrões de design a seguir. Você pode fazer DI manualmente usando o chamado PM do pobre, mas obviamente fica muito melhor com um contêiner DI.

    Por que isso é relevante? Isso é relevante porque, uma vez que você perceba isso, o corolário é que a grande maioria do código de seu aplicativo não deve ter conhecimento do Contêiner DI que está por vir.

    Então, onde você usa o contêiner DI? Ele só deve ser usado em uma raiz de composição , que no seu caso corresponderia a Global.asax. Você pode ler um pouco mais sobre isso nessa resposta – embora essa questão seja sobre Windsor, o princípio permanece o mesmo.

    Como sobre seus testes de unidade então? Eles devem ser completamente ignorantes do contêiner DI também. Veja esta outra resposta para mais detalhes.

    DI pode ser alcançado em sua biblioteca com uso copioso de Injeção de Construtor . Você não precisa fazer referência a qualquer Contêiner DI para fazer isso, mas facilita muito a vida se você usar um Contêiner DI para resolver todas as dependencies da Raiz de Composição.