Iniezione delle dipendenze in un'applicazione di livello n?

Question

Ho un'app di servizio .NET a 3 livelli, che segue l'approccio standard:

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

Sto cercando di conoscere l'iniezione di dipendenza lungo la strada, e finora l'ho trovata fantastica (usando Autofac). Ognuno dei 3 livelli deve creare un assortimento di oggetti, a volte con una configurazione / etc aggiuntiva. Sembra che il contenitore DI dovrebbe essere la cosa ideale per risolvere questo problema, ma sto riscontrando alcuni problemi nel vedere dove dovrebbe vivere in relazione al resto del sistema.

Attualmente ho una classe nel frontend che configura il contenitore DI. Fondamentalmente è un grosso mucchio di codice che dice container.Register<SomeType>() e così via.

Il problema è che sta configurando il contenitore per tutti e 3 i livelli, e quindi deve avere una conoscenza abbastanza invasiva del livello di accesso ai dati. Avere il codice nel mio frontend con una tale conoscenza fa scattare campanelli d'allarme nella mia testa come il punto di separazione dell'app in livelli è quello di evitare questa situazione esatta.
Ciò è anche peggiorato dal fatto che il mio livello di accesso ai dati non è solo un server SQL che è un muto bucket di bit, ma è composto da molte interazioni COM complesse e chiamate P / Invoke, quindi ha un impatto notevole sul DI configurazione.

Ho pensato di romperlo - forse avendo un contenitore per livello o avendo un " Setup " classe in ogni livello che parla al contenitore DI globale per registrare i propri bit, ma non sono sicuro che ciò causerà più problemi di quanti ne risolva ...

Gradirei davvero che qualcuno potesse condividere le proprie esperienze nell'uso di DI con app a più livelli.

Grazie, Orion.

Answer 1

Dipende se hai tre livelli (separazione fisica) o se tutti i tuoi livelli logici sono distribuiti insieme. Se il frontend è separato dal BL e comunica tramite un servizio Web o WCF, il frontend e il backend necessitano dei propri contenitori perché sono in esecuzione in processi o macchine separate. I contenitori registrerebbero solo i propri componenti e le interfacce del livello "successivo".

D'altra parte se tutti i layer sono in esecuzione nello stesso processo, allora dovresti avere un solo contenitore. Il contenitore verrebbe inizializzato e ospitato nel punto iniziale dell'applicazione come global.asax per un'app Web.

Il problema con l'host contenitore che conosce gran parte delle diverse parti del sistema potrebbe essere risolto non registrando le classi una per una, ma invece registrando tutti i tipi in un assembly. In questo modo non sono necessari riferimenti forti a tutti gli assembly nella soluzione solo per configurare il contenitore. Esempio di come si può fare con Castle Winsdor:

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