Respondiendo a mi propia publicación después de un par de años de usar NInject.
Así es como puedo organizar mis NInjectModules, usando una librería como un ejemplo:
- BookStoreSolution
- Domain.csproj
- Services.csproj
- CustomerServicesInjectionModule.cs
- PaymentProcessingInjectionModule.cs
- DataAccess.csproj
- CustomerDatabaseInjectionModule.cs
- BookDatabaseInjectionModule.cs
- CustomSecurityFramework.csproj
- CustomSecurityFrameworkInjectionModule.cs
- PublicWebsite.csproj
- PublicWebsiteInjectionModule.cs
- Intranet.csproj
- IntranetInjectionModule.cs
Lo que esto quiere decir es que cada proyecto en el sistema viene preenvasado con uno o más NInject módulos que saben cómo configurar los enlaces para las clases de ese proyecto.
La mayoría de las veces una aplicación individual no va a querer hacer cambios significativos en los módulos de inyección predeterminados proporcionados por un proyecto. Por ejemplo, si estoy creando una pequeña aplicación de WinForm que necesita importar el proyecto de DataAccess, normalmente también querré tener todas las clases de Repository <> del proyecto vinculadas a sus interfaces IRepository <> asociadas.
Al mismo tiempo, no hay nada que obligue a una aplicación individual a usar un módulo de inyección en particular.Una aplicación puede crear su propio módulo de inyección e ignorar los módulos predeterminados proporcionados por un proyecto que está importando. De esta forma, el sistema sigue siendo flexible y desacoplado.
Buena pregunta. Me gustaría ver más discusión de esto mientras comparto sus preocupaciones. Tener un módulo por subsistema parece razonable, pero también tengo módulos para cablear las dependencias de forma diferente para las pruebas unitarias. – JulianM