Dove devo fare Injection con Ninject 2+ (e come sistemare i miei moduli?)

Question

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

1. Libreria di classi con funzionalità utilizzate 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 specifica sessione oggetti (pensa Unità di lavoro).
• L'app MVC ha bisogno di DI poiché con Ninject 2 si eredita fondamentalmente da NinjectHttpApplication.
• I test di unità per la libreria di classi devono essere consapevoli di ciò per iniettare un diverso insieme di repository.
• I test unitari per l'app Web devono essere iniettati per lo stesso motivo.

Qui mi sono dipinto in un angolo mentale, perché ho visto solo tre opzioni per cominciare. DI nella libreria di classi, DI nella web app, o 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 iniziare con.
• Non riesco a fare DI solo nell'app MVC - la libreria di classi è utilizzata da altre librerie, dopotutto, e l'app MVC non dovrebbe comunque conoscere troppo gli interni della libreria.
• Immagino che questa sia l'unica via d'uscita che posso vedere: IoC indipendente per entrambi i progetti. La libreria di classi e l'app MVC hanno ciascuno la propria configurazione IoC e fanno DI per le loro cose senza preoccuparsi l'una dell'altra.

Qualcuno ha alcune "migliori pratiche" o linee guida su come fare qualcosa di simile? Non riesco a immaginare di essere la prima persona a finire in questa situazione, e sarebbe sicuramente bello sapere qual è il modo "corretto" per farlo ...

Grazie!

Answer 1

Non conosco NInject, ma a meno che funzioni in modo molto diverso da Windsor, StructureMap ecc. Le risposte tendono a rimanere invariate, in quanto vi sono alcuni DI pattern comuni. Con questo in mente:

La prima cosa da capire è che DI non è legato a un particolare framework come NInject o Windsor. È un insieme di tecniche e modelli di progettazione da seguire. Puoi fare DI manualmente usando il cosiddetto DI di Poor Man, ma ovviamente diventa molto meglio con un DI Container.

Perché è rilevante? È importante perché una volta capito questo, il corollario è che la stragrande maggioranza del codice della tua applicazione deve avere la conoscenza no del DI Container.

Quindi, dove si utilizza il contenitore DI? Dovrebbe essere utilizzato solo in una radice di composizione , che nel tuo caso corrisponderebbe a Global.asax.Puoi leggere un po 'di più su questo in this SO answer - sebbene quella domanda riguardi Windsor, il principio rimane lo stesso.

E i test delle unità? Dovrebbero essere completamente ignoranti anche del contenitore DI. Vedi this other SO answer per maggiori dettagli.

DI può essere raggiunto nel proprio archivio con un uso notevole di Iniezione costruttore. Non è necessario fare riferimento a nessun contenitore DI per farlo, ma rende la vita molto più semplice se si utilizza un contenitore DI per risolvere tutte le dipendenze dalla radice di composizione.