La spiegazione più semplice di come funziona un contenitore DI?

Question

In termini semplici e/o in pseudo-codice di alto livello, come funziona un contenitore DI e come viene utilizzato?

Answer 1

Al suo interno un contenitore DI crea oggetti basati sui mapping tra interfacce e tipi di calcestruzzo.

Questo vi permetterà di richiedere un tipo astratto dal contenitore:

IFoo f = container.Resolve<IFoo>(); 

Questo richiede di avere in precedenza configurato il contenitore per mappare da IFoo a una classe concreta che implementa IFoo (ad esempio Foo).

Questo di per sé non sarebbe particolarmente impressionante, ma Di Container fare di più:

• Essi usano Auto-cablaggio che significa che essi possono calcolare automaticamente che se IFoo mappe di Foo e mappe IBar a Bar, ma Foo ha una dipendenza da IBar, creerà un'istanza Foo con una barra quando richiedi IFoo.
• Gestiscono la durata della vita dei componenti. Molti vogliono una nuova istanza di Foo ogni volta, ma in altri casi si potrebbe desiderare la stessa istanza. Potresti anche volere nuove istanze di Foo ogni volta, ma la barra iniettata dovrebbe rimanere la stessa istanza.

volta che si inizia cercando di gestire manualmente composizione e vite si dovrebbe iniziare ad apprezzare i servizi forniti da un contenitore DI :)

Molti DI Container può fare molto di più di quanto sopra, ma quelli sono i servizi di base. La maggior parte dei contenitori offre opzioni per configuring via either code or XML.

Quando si tratta di utilizzare l' di contenitori, Krzysztof Kozmic ha appena pubblicato a good overview.

Answer 2

Si configura un contenitore DI in modo che conosca le proprie interfacce e tipi - il modo in cui ogni interfaccia si associa a un tipo.

Quando si chiama Resolve su di esso, esamina la mappatura e restituisce l'oggetto mappato richiesto.

Alcuni contenitori DI utilizzano le convenzioni sulla configurazione, dove, ad esempio, se si definisce un'interfaccia ISomething, verrà cercato un tipo di Something concreto da istanziare e restituire.

Answer 3

"non è niente più che una fantasia hash tabella di oggetti."

Mentre il sopra è un eufemismo enorme che è il modo più semplice di pensare a loro. Data la raccolta, se si richiede la stessa istanza di una classe, il contenitore DI deciderà se fornire una versione memorizzata nella cache o una nuova o così via.

Il loro utilizzo rende più semplice e più pulito il cablaggio delle dipendenze. Immagina di avere le seguenti pseudo classi.

class House(Kitchen, Bedroom) 
    // Use kitchen and bedroom. 
end 

class Kitchen() 
    // Code... 
end 

class Bedroom() 
    // Code... 
end 

Costruire una casa è un dolore senza un contenitore DI, si avrebbe bisogno di creare un'istanza di una camera da letto, seguita da un'istanza di una cucina. Se anche quegli oggetti avevano delle dipendenze, dovresti collegarli. A sua volta, puoi spendere molte linee di codice semplicemente collegando gli oggetti. Solo allora potresti creare una casa valida. Usando un contenitore DI/IOC (Inversion of Control) si dice che si desidera un oggetto casa, il contenitore DI creerà ricorsivamente ciascuna delle sue dipendenze e restituirà una casa.

Senza DI/IOC container:

house = new House(new Kitchen(), new Bedroom()); 

Con DI/IOC container:

house = // some method of getting the house 

Alla fine della giornata fanno codice facile da seguire, più facile da scrivere e spostare la responsabilità di collegare gli oggetti insieme lontano dal problema in questione.