Ioc / DI - Perché devo fare riferimento a tutti i layer / assembly nel punto di ingresso dell'applicazione?

(In relazione a questa domanda, EF4: perché la creazione del proxy deve essere abilitata quando è abilitato il caricamento lento? ).

Sono nuovo in DI, quindi abbi pazienza. Comprendo che il contenitore è incaricato di creare un'istanza di tutti i miei tipi registrati, ma per farlo richiede un riferimento a tutte le DLL nella mia soluzione e ai loro riferimenti.

Se non stessi utilizzando un contenitore DI, non avrei dovuto fare riferimento alla libreria EntityFramework nella mia app MVC3, ma solo al mio livello aziendale, che farebbe riferimento al mio livello DAL / Repo.

So che alla fine della giornata tutte le DLL sono incluse nella cartella bin, ma il mio problema è doverle fare riferimento esplicitamente tramite "aggiungi riferimento" in VS per poter pubblicare un WAP con tutti i file necessari.

Se non stessi utilizzando un contenitore DI, non avrei dovuto fare riferimento alla libreria EntityFramework nella mia app MVC3, solo il mio livello aziendale che farebbe riferimento al mio livello DAL / Repo.

Sì, è esattamente la situazione che DI lavora così duramente per evitare :)

Con codice strettamente accoppiato, ogni libreria può avere solo pochi riferimenti, ma anche questi hanno altri riferimenti, creando un grafico profondo delle dipendenze, come questo:

Poiché il grafico delle dipendenze è profondo, significa che la maggior parte biblioteche trascinano molte altre dipendenze - ad esempio nel diagramma, biblioteca C trascina libreria H, biblioteca E, biblioteca J, biblioteca M, biblioteca K e biblioteca N . Ciò rende più difficile riutilizzare ogni libreria indipendentemente dal resto, ad esempio nei test di unità .

Tuttavia, in un'applicazione debolmente accoppiata, spostando tutti i riferimenti alla radice della composizione , il grafico delle dipendenze viene notevolmente appiattito :

Come illustrato dal colore verde, ora è possibile riutilizzare la Libreria C senza trascinare dipendenze indesiderate.

Tuttavia, tutto ciò detto, con molti contenitori DI, non è necessario aggiungere riferimenti a tutte le librerie richieste. È invece possibile utilizzare l' associazione tardiva sotto forma di scansione dell'assembly basata su convenzione (preferita) o configurazione XML.

Quando lo fai, tuttavia, devi ricordarti di copiare gli assembly nella cartella bin dell'applicazione, perché ciò non avviene più automaticamente. Personalmente, trovo raramente che valga questo sforzo extra.

Una versione più elaborata di questa risposta può essere trovata in questo estratto dal mio libro Dependency Injection, Principles, Practices, Patterns .

Se non stessi utilizzando un contenitore DI, non avrei dovuto fare riferimento alla libreria EntityFramework nella mia app MVC3

Anche quando si utilizza un contenitore DI, non è necessario lasciare che il progetto MVC3 faccia riferimento a EF, ma si sceglie (implicitamente) di farlo implementando la radice della composizione (il percorso di avvio in cui si compongono i grafici degli oggetti) all'interno del progetto MVC3. Se sei molto severo sulla protezione dei tuoi confini architettonici utilizzando gli assembly, puoi spostare la logica di presentazione in un progetto diverso.

Quando si sposta tutta la logica correlata a MVC (controller, ecc.) Dal progetto di avvio a una libreria di classi, si consente a questo assembly del livello di presentazione di rimanere disconnesso dal resto dell'applicazione. Il progetto dell'applicazione web stesso diventerà un guscio molto sottile con la logica di avvio richiesta. Il progetto dell'applicazione Web sarà la radice della composizione che fa riferimento a tutti gli altri assembly.

L'estrazione della logica di presentazione in una libreria di classi può complicare le cose quando si lavora con MVC. Sarà più difficile collegare tutto, poiché i controller non sono nel progetto di avvio (mentre viste, immagini, file css, devono probabilmente rimanere nel progetto di avvio). Questo è probabilmente fattibile ma richiederà più tempo per la configurazione.

A causa degli svantaggi, in genere consiglio di mantenere la radice della composizione nel progetto web. Molti sviluppatori non vogliono che il loro assembly MVC dipenda dall'assembly DAL, ma non è davvero un problema. Non dimenticare che gli assembly sono un artefatto di distribuzione ; si divide il codice in più assembly per consentire la distribuzione separata del codice. Uno strato architettonico d'altra parte è un artefatto logico . È molto possibile (e comune) avere più livelli nello stesso assieme.

In questo caso finiremo per avere la radice della composizione (livello) e il livello di presentazione nello stesso progetto di applicazione web (quindi nello stesso assieme). E anche se quell'assembly fa riferimento all'assembly contenente il DAL, il livello di presentazione non fa ancora riferimento al livello di accesso ai dati . Questa è una grande distinzione.

Ovviamente, quando lo facciamo, perdiamo la capacità del compilatore di controllare questa regola architettonica in fase di compilazione, ma questo non dovrebbe essere un problema. La maggior parte delle regole architetturali in realtà non può essere verificata dal compilatore e c'è sempre qualcosa come il buon senso. E se non c'è buon senso nel tuo team, puoi sempre usare le revisioni del codice (che ogni team dovrebbe fare sempre IMO). Puoi anche utilizzare uno strumento come NDepend (che è commerciale), che ti aiuta a verificare le tue regole architetturali. Quando si integra NDepend con il processo di compilazione, può avvisarti quando qualcuno ha controllato il codice che viola tale regola architettonica.

Puoi leggere una discussione più elaborata su come funziona la radice della composizione nel capitolo 4 del mio libro Dependency Injection, Principles, Practices, Patterns .

Se non stessi utilizzando un contenitore DI, non avrei dovuto fare riferimento alla libreria EntityFramework nella mia app MVC3, solo il mio livello aziendale che farebbe riferimento al mio livello DAL / Repo.

È possibile creare un progetto separato chiamato "DependencyResolver". In questo progetto devi fare riferimento a tutte le tue librerie.

Ora il livello dell'interfaccia utente non necessita di NHibernate / EF o di qualsiasi altra libreria non pertinente per l'interfaccia utente ad eccezione di Castle Windsor per essere referenziato.

Se si desidera nascondere Castle Windsor e DependencyResolver dal livello dell'interfaccia utente, è possibile scrivere un HttpModule che richiami gli elementi del registro di IoC.

Ho solo un esempio per StructureMap:

public class DependencyRegistrarModule : IHttpModule
{
    private static bool _dependenciesRegistered;
    private static readonly object Lock = new object();

    public void Init(HttpApplication context)
    {
        context.BeginRequest += (sender, args) => EnsureDependenciesRegistered();
    }

    public void Dispose() { }

    private static void EnsureDependenciesRegistered()
    {
        if (!_dependenciesRegistered)
        {
            lock (Lock)
            {
                if (!_dependenciesRegistered)
                {
                    ObjectFactory.ResetDefaults();

                    // Register all you dependencies here
                    ObjectFactory.Initialize(x => x.AddRegistry(new DependencyRegistry()));

                    new InitiailizeDefaultFactories().Configure();
                    _dependenciesRegistered = true;
                }
            }
        }
    }
}

public class InitiailizeDefaultFactories
{
    public void Configure()
    {
        StructureMapControllerFactory.GetController = type => ObjectFactory.GetInstance(type);
          ...
    }
 }

DefaultControllerFactory non usa direttamente il contenitore IoC, ma delega ai metodi del contenitore IoC.

public class StructureMapControllerFactory : DefaultControllerFactory
{
    public static Func<Type, object> GetController = type =>
    {
        throw new  InvalidOperationException("The dependency callback for the StructureMapControllerFactory is not configured!");
    };

    protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
    {
        if (controllerType == null)
        {
            return base.GetControllerInstance(requestContext, controllerType);
        }
        return GetController(controllerType) as Controller;
    }
}

Il GetControllerdelegato è impostato in un registro StructureMap (in Windsor dovrebbe essere un programma di installazione).

• C'è una dipendenza: se un oggetto crea un'istanza di un altro oggetto.
• Non c'è dipendenza: se un oggetto si aspetta un'astrazione (iniezione del costruttore, iniezione del metodo ...)
• I riferimenti ad assembly (che fanno riferimento a dll, webservices ..) sono indipendenti dal concetto di dipendenza, perché per risolvere un'astrazione ed essere in grado di compilare il codice, il livello deve fare riferimento ad essa.