Ho visto molti riferimenti di Dependency Injection (DI) & Inversion Of Control (IOC), ma non so se c'è una differenza tra loro o meno.
Vorrei iniziare a utilizzare uno o entrambi, ma sono un po 'confuso su come sono diversi.
Definizioni
L'inversione del controllo è un paradigma di progettazione con l'obiettivo di ridurre la consapevolezza delle implementazioni concrete dal codice del framework dell'applicazione e dare maggiore controllo ai componenti specifici del dominio dell'applicazione. In un sistema tradizionale top down progettato, il flusso logico di consapevolezza delle applicazioni e delle dipendenze deriva dai componenti principali, quelli progettati in primo luogo, a quelli progettati per ultimi. In quanto tale, l'inversione di controllo è un'inversione quasi letterale della consapevolezza di controllo e dipendenza in un'applicazione.
L'injection dependance è un pattern utilizzato per creare istanze di classi su cui fanno affidamento altre classi senza sapere in fase di compilazione quale implementazione verrà utilizzata per fornire tale funzionalità.
Lavorando insieme
L'inversione del controllo può utilizzare l'iniezione di dipendenza perché è necessario un meccanismo per creare i componenti che forniscono la funzionalità specifica. Esistono altre opzioni e vengono utilizzate, ad es. attivatori, metodi di fabbrica, ecc., ma i framework non hanno bisogno di fare riferimento a tali classi di utilità quando le classi del framework possono accettare le dipendenze di cui hanno invece bisogno.
Esempi
Un esempio di questi concetti al lavoro è il framework plug-in in Reflector . I plug-in hanno un grande controllo del sistema anche se l'applicazione non sapeva nulla dei plug-in al momento della compilazione. Su ciascuno di questi plug-in viene chiamato un singolo metodo, Initialize if memory serve, che passa il controllo al plug-in. Il quadro non sa quello che faranno, semplicemente gli permetterà di farlo. Il controllo è stato preso dall'applicazione principale e dato al componente che esegue il lavoro specifico; inversione di controllo.
Il framework dell'applicazione consente l'accesso alle sue funzionalità attraverso una varietà di fornitori di servizi. A un plug-in vengono forniti riferimenti ai provider di servizi al momento della creazione. Queste dipendenze consentono al plug-in di aggiungere le proprie voci di menu, modificare la modalità di visualizzazione dei file, visualizzare le proprie informazioni nei pannelli appropriati, ecc. Poiché le dipendenze vengono passate dall'interfaccia, le implementazioni possono cambiare e le modifiche non interromperanno codice finché il contratto rimane intatto.
Al momento, è stato utilizzato un metodo factory per creare i plug-in utilizzando le informazioni di configurazione, reflection e l'oggetto Activator (almeno in .NET). Oggi ci sono strumenti, MEF per uno, che consentono una gamma più ampia di opzioni quando si iniettano dipendenze, inclusa la possibilità per un framework di applicazioni di accettare un elenco di plug-in come dipendenza.
Riepilogo
Sebbene questi concetti possano essere utilizzati e fornire vantaggi indipendentemente, insieme consentono di scrivere codice molto più flessibile, riutilizzabile e verificabile. In quanto tali, sono concetti importanti nella progettazione di soluzioni orientate agli oggetti.
Buon articolo per comprendere IOC e DI link
IOC (Inversion of Control)
IOC significa
codifica per interfaccia (un componente dovrebbe dipendere dall'interfaccia di altri componenti e non da impl), e ad es.
interface iComp_2 {...}
class Comp_1 {
iComp_2 c2 = ….;
}
rimozione del codice specifico di implementazione del componente ad es.
Comp_1 {
iComp_2 c2 = getComp_2_Impl(); // not new Comp_2_Impl();
}
IOC può essere ottenuto con uno dei seguenti:
1. DI (Dipendenza iniezione)
3 types of DI
1.1 Constructor Injection
1.2 Setter Injection
1.3 Interface Injection
2. Service Locator
contenitore DI (Dependency Injection)
Determinazione impl di Runtime e non tempo di compilazione: determina in fase di esecuzione quale implementazione concreta di un'interfaccia deve essere utilizzata in base ad alcuni file di configurazione (quindi al momento della compilazione non sappiamo quale impl verrà utilizzato e quindi aumenta la configurabilità di l'applicazione). È un'implementazione in cui la relazione concreta tra i diversi moduli viene decisa in "tempo di esecuzione".
Istanziazione di impl dopo l'iniezione di dipendenza: dopo aver determinato l'impl, essa istanzia quella impl creando prima tutte le sue dipendenze (specificate nel file di configurazione) e poi iniettando quelle dipendenze in quell'imp
Gestione del ciclo di vita dell'istanza: i contenitori DI in genere conservano solo un riferimento agli oggetti di cui ha bisogno per gestire i cicli di vita, o che vengono riutilizzati per iniezioni future, come singleton o flyweights. Quando configurato per creare nuove istanze di alcuni componenti per ogni chiamata al contenitore, il contenitore di solito si dimentica solo dell'oggetto creato. Altrimenti il garbage collector avrebbe difficoltà a raccogliere tutti questi oggetti quando non sono più utilizzati.
Direi "Inversion of Control" è un modo per progettare un sistema in cui tutti i moduli sono pensati come entità astratte.
E, "Dependency Injection" è un'implementazione in cui la relazione concreta tra diversi moduli viene decisa in "run time".
L'inversione del controllo è un concetto generale, nei linguaggi funzionali si fa solitamente usando le continuazioni. Questo ti permette di scrivere un'API in cui entrambi i lati sono "chiamanti" e nessuno "callee". In altri, più ambienti statici non hai questa facilità, quindi hai bisogno di questo trucco per inserire suggerimenti nel flusso di controllo.
Leggi altre domande sui tag dependency-injection inversion-of-control