.NET FrameworkIniezione di dipendenza

Osservazioni

Problemi risolti dall'iniezione delle dipendenze

Se non si utilizza l'iniezione di dipendenza, la classe Greeter potrebbe essere più simile a questa:

public class ControlFreakGreeter
{
    public void Greet()
    {
        var greetingProvider = new SqlGreetingProvider(
            ConfigurationManager.ConnectionStrings["myConnectionString"].ConnectionString);
        var greeting = greetingProvider.GetGreeting();
        Console.WriteLine(greeting);
    }
}

È un "maniaco del controllo" perché controlla la creazione della classe che fornisce il saluto, controlla da dove proviene la stringa di connessione SQL e controlla l'output.

Usando l'iniezione di dipendenza, la classe Greeter rinuncia a quelle responsabilità a favore di una singola responsabilità, scrivendo un saluto fornito ad essa.

Il principio di inversione di dipendenza suggerisce che le classi dovrebbero dipendere dalle astrazioni (come le interfacce) piuttosto che da altre classi concrete. Le dipendenze dirette (accoppiamento) tra classi possono rendere la manutenzione progressivamente difficile. A seconda delle astrazioni è possibile ridurre tale accoppiamento.

L'iniezione di dipendenza ci aiuta a raggiungere tale inversione di dipendenza perché conduce a scrivere classi che dipendono dalle astrazioni. La classe Greeter "non sa" nulla dei dettagli di implementazione di IGreetingProvider e IGreetingWriter . Sa solo che le dipendenze iniettate implementano quelle interfacce. Ciò significa che le modifiche alle classi concrete che implementano IGreetingProvider e IGreetingWriter non influiranno su Greeter . Né li sostituiranno con implementazioni completamente diverse. Verranno modificate solo le interfacce. Greeter è disaccoppiato.

ControlFreakGreeter è impossibile eseguire correttamente il test dell'unità. Vogliamo testare una piccola unità di codice, ma il nostro test includerebbe la connessione a SQL e l'esecuzione di una stored procedure. Includerebbe anche il test dell'output della console. Poiché ControlFreakGreeter fa così tanto è impossibile testare separatamente dalle altre classi.

Greeter è facile da testare in quanto è possibile iniettare implementazioni derise delle sue dipendenze che sono più facili da eseguire e verificare rispetto alla chiamata di una stored procedure o alla lettura dell'output della console. Non richiede una stringa di connessione in app.config.

Le implementazioni concrete di IGreetingProvider e IGreetingWriter potrebbero diventare più complesse. A loro volta, potrebbero avere le loro dipendenze che vengono iniettate in loro. (Ad esempio, inseriremmo la stringa di connessione SQL in SqlGreetingProvider .) Ma quella complessità è "nascosta" da altre classi che dipendono solo dalle interfacce. Ciò rende più semplice modificare una classe senza un "effetto a catena" che richiede di apportare modifiche corrispondenti ad altre classi.

Iniezione di dipendenza Esempi correlati