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 .