I vantaggi di risoluzione delle dipendenze e il CIO in asp.net mvc

Question

Eventuali duplicati:
Why do I need an IoC container as opposed to straightforward DI code?

Ho letto alcuni articoli su questo argomento e non ho trovato alcun vantaggio brillanti. Per esempio questo codice:

//some action in a controller 
//simplest solution: 
var repository = new EmployeeRepository(); 
var model = repository.ListAllEmployees(); 

così si può dire: in questa soluzione, il controller/azione molto dipende dalla EmployeeRepository. La risoluzione delle dipendenze è:

var repository = DependencyResolver.Current.GetService<IEmployeeRepository>(); 
var model = repository.ListAllEmployees(); 

non ho trovato di meglio di quello successivo, senza alcuna risoluzione delle dipendenze/CIO:

var model = Managers.EmployeeManager.ListAllEmployees(); 

La speranza che qualcuno mi può dare alcune idee/link/messaggi su questo argomento.

Answer 1

Il principale vantaggio dell'inversione del controllo è il disaccoppiamento. Disaccoppiando si migliora la manutenibilità. Il controller/azione dipende dall'interfaccia e l'implementazione viene iniettata nel controller.

La risoluzione delle dipendenze attraverso un contenitore IoC semplifica la logica di dipendenza delle dipendenze per il controllore configurando il contenitore. Dove questo diventa veramente chiaro è se una classe dipende da un servizio, quel servizio dipende da altri servizi e tali servizi potrebbero anche dipendere da più servizi, il contenitore gestirà tale risoluzione delle dipendenze.

Un sacco di persone potrebbero dirti di implementare l'inversione del controllo per essere in grado di testare il tuo codice, questo non è ciò che l'inversione di controllo offre, rende il tuo codice più testabile ma non è la ragione principale.

Answer 2

Il tuo esempio con DependencyResolver non è molto meglio del tuo codice originale, quindi sì ... non c'è molto vantaggio nel farlo.

Per fortuna, questo non è il modo in cui dovresti farlo. Invece, si usa la funzione di costruzione o l'iniezione di proprietà.

Sono d'accordo con @adriaanp, un test dell'unità più semplice è solo un vantaggio collaterale dell'iniezione di dipendenza. Il più grande vantaggio è che incoraggia l'architettura senza dipendenza. Le classi sono indipendenti e non dipendono da un'implementazione specifica (diversa dall'interfaccia e dai requisiti)

Un altro vantaggio è che un contenitore IoC può controllare la durata delle dipendenze. Supponiamo che tu voglia che un oggetto esista per tutta la durata della richiesta nella pagina web. Supponiamo anche di voler accedere a questo oggetto in molte classi diverse. Puoi creare l'oggetto nel tuo evento di caricamento della pagina, quindi passarlo a tutti gli oggetti creati che ne hanno bisogno. Tuttavia, questo può significare che devi passare ad oggetti che in realtà non lo usano, semplicemente perché creano oggetti che ne hanno bisogno (oppure creano oggetti che creano oggetti che ne hanno bisogno, o .. e così via).

Con l'iniezione delle dipendenze e un contenitore IoC, il contenitore controlla la durata dell'oggetto e si occupa di iniettarlo negli oggetti che ne hanno bisogno. Non devi costruirlo nei tuoi progetti. Lo prendi gratis.

E infine, per il problema di test.Quando provi qualcosa, se ha una nuova codifica, non puoi facilmente sostituirlo con un oggetto deriso per alimentarlo. Supponiamo di voler verificare che un oggetto calcoli correttamente un valore. Alimentarlo con dati noti con valori noti facilita il test.