Looking for .net Answers? Try Ask4KnowledgeBase
Looking for .net Keywords? Try Ask4Keywords

.NET FrameworkInjection de dépendance


Remarques

Problèmes résolus par injection de dépendance

Si nous n'utilisions pas d'injection de dépendance, la classe Greeter pourrait ressembler davantage à ceci:

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

C'est un "contrôle freak" car il contrôle la création de la classe qui fournit le message d'accueil, il contrôle la provenance de la chaîne de connexion SQL et contrôle la sortie.

En utilisant l'injection de dépendance, la classe Greeter renonce à ces responsabilités en faveur d'une responsabilité unique, en lui écrivant un message d'accueil.

Le principe d'inversion de dépendance suggère que les classes devraient dépendre des abstractions (comme les interfaces) plutôt que d'autres classes concrètes. Les dépendances directes (couplage) entre classes peuvent rendre la maintenance progressivement difficile. Selon les abstractions peuvent réduire ce couplage.

L'injection de dépendance nous aide à réaliser cette inversion de dépendance car elle conduit à écrire des classes qui dépendent des abstractions. La classe Greeter "sait" rien des détails d' IGreetingProvider de IGreetingProvider et IGreetingWriter . Il sait seulement que les dépendances injectées implémentent ces interfaces. Cela signifie que les modifications apportées aux classes concrètes qui implémentent IGreetingProvider et IGreetingWriter n'affecteront pas Greeter . Ne les remplaceront pas non plus par des implémentations entièrement différentes. Seules les modifications apportées aux interfaces le seront. Greeter est découplé.

ControlFreakGreeter est impossible à tester correctement. Nous voulons tester une petite unité de code, mais à la place, notre test comprendra la connexion à SQL et l'exécution d'une procédure stockée. Il faudrait également tester la sortie de la console. Parce que ControlFreakGreeter fait tellement de choses, il est impossible de tester indépendamment des autres classes.

Greeter est facile à tester car nous pouvons injecter des implémentations simulées de ses dépendances qui sont plus faciles à exécuter et à vérifier qu’à appeler une procédure stockée ou à lire la sortie de la console. Il ne nécessite pas de chaîne de connexion dans app.config.

Les implémentations concrètes de IGreetingProvider et IGreetingWriter pourraient devenir plus complexes. Ils peuvent à leur tour avoir leurs propres dépendances qui leur sont injectées. (Par exemple, nous injecterions la chaîne de connexion SQL dans SqlGreetingProvider .) Mais cette complexité est "cachée" des autres classes qui ne dépendent que des interfaces. Cela facilite la modification d'une classe sans "effet d'entraînement", ce qui nous oblige à apporter des modifications correspondantes aux autres classes.

Injection de dépendance Exemples Liés