Dove devo fare Iniezione con Ninject 2+ (e come faccio a organizzare i miei moduli?)

Question

Ho una soluzione con due (a questa domanda) progetti pertinenti, e pochi altri;

1. libreria di classi con funzionalità utilizzato da diversi altri progetti.
2. applicazione ASP.NET MVC.

La mia domanda è fondamentalmente in cui devo fare IoC con Ninject 2, considerando ...

• La libreria di classi ha bisogno di qualche amore DI, tra le altre cose nelle classi repository che necessitano di richiesta Web oggetti di sessione specifica (si pensi unità di lavoro).
• Il MVC applicazione ha bisogno DI poiché con Ninject 2 che, fondamentalmente, eredita dai NinjectHttpApplication.
• Prove di unità per la libreria di classi devono essere consapevoli di questo per iniettare un diverso insieme di repository.
• test unitari per la web app devono essere iniettati per la stessa ragione.

Mi sono dipinte in un angolo mentale qui, perché ho visto solo tre opzioni per cominciare. DI nella libreria di classi, DI nella web app, o di entrambi, ma ci sono problemi con ciascuno:

• Non posso farlo DI solo nella libreria di classi in quanto l'applicazione MVC ha bisogno di ereditare da NinjectHttpApplication per cominciare.
• Non riesco a fare DI solo in app MVC - la libreria di classi viene utilizzato da altre biblioteche, dopo tutto, e l'applicazione MVC non dovrebbe sapere troppo riguardo la struttura interna della libreria comunque
.
• Credo che questa è l'unica via d'uscita che posso vedere: Autonomo CIO per entrambi i progetti. La libreria di classi e l'applicazione MVC hanno ciascuno la propria configurazione CIO e fanno DI per le loro cose senza realmente curarsi a vicenda.

Qualcuno ha alcune "buone pratiche" o linee guida su come fare qualcosa di simile? Non riesco a immaginare io sono la prima persona a finire in questa situazione, e sarebbe certo bello sapere ciò che il modo "corretto" per farlo è ...

Grazie!

Answer 1

Non so Ninject, ma se non funziona molto diverso rispetto Windsor, StructureMap ecc le risposte tendono a rimanere lo stesso, in quanto vi sono alcuni modelli DI comuni. Con questo in mente:

La prima cosa da capire è che Di non è legato a un quadro particolare, come Ninject o Windsor. Si tratta di un insieme di tecniche e modelli di progettazione da seguire. Si può fare manualmente usando DI cosiddetto povero di DI, ma ovviamente diventa molto meglio con un contenitore DI.

Perché questo è rilevante? E 'importante perché una volta che ci si rende conto questo, il corollario è che la stragrande maggioranza degli codice dell'applicazione dovrebbe avere non conoscenza del contenitore DI whatsover.

Allora, dove si usa il DI container? Dovrebbe essere usato solo in un Composizione Root , che nel tuo caso corrisponderebbe a Global.asax. Si può leggere un po 'di più su questo in questo SO rispondere -. anche se questa domanda è su Windsor, il principio rimane lo stesso

Come circa i vostri test di unità, allora? Essi dovrebbero essere completamente all'oscuro del DI contenitore così. Vedere questo altro SO rispondere per ulteriori dettagli.

DI può essere raggiunto nella libreria con l'uso abbondante di Constructor iniezione . Non è necessario fare riferimento a qualsiasi DI Contenitore per farlo, ma rende la vita molto più facile se si utilizza un DI Container per risolvere tutte le dipendenze dalla radice Composizione.