Frais généraux liés à l'utilisation de l'injection de dépendance

Question

L’injection de dépendance entraîne-t-elle potentiellement une surcharge importante?

J'imagine que oui, en particulier si le résolveur est appelé plusieurs fois (ce qui est très probablement basé sur des exemples de motifs)? Ou est-ce que je me trompe? Malheureusement, je ne peux pas tester moi-même car je ne l’ai jamais utilisé, mais j’ai prévu de l’utiliser.

Answer 1

Sauf si vous utilisez un service de localisation , je doute que les frais généraux faire une différence significative. (Même si vous l'êtes, il est peu probable que ce soit significatif.)

En utilisant l'injection du constructeur et un cadre moderne, le résolveur sera appelé lors de la construction des objets. Dans la plupart des cas, je suppose que vous constaterez que les objets avec des dépendances sont des composants de haut niveau, de longue durée de vie ou les deux.

Si vous utilisez un conteneur IoC et créez un lot d'objets avec des dépendances dans une boucle étroite, vous devrez peut-être faire une optimisation. Vous pouvez toujours le profiler ou le comparer.

En bref, je ne m'inquiéterais pas pour ça.

Answer 2

L'injection de dépendances en tant que concept n'a pas besoin de beaucoup de temps système: il s'agit simplement de structurer une classe de sorte que ses connexions avec d'autres classes puissent être construites au moment de l'exécution plutôt que d'être câblées dans le code.

Bien sûr, il existe des moyens de créer cette connexion au moment de l’exécution qui pourrait être très onéreux. Évitez ces moyens.

Answer 3

http://www.codinginstinct.com /2008/04/ioc-container-benchmark-unity-windsor.html pour certains tests de performances. Chaque test exécutait 1000000 créations.

Notez que le repère indique la résolution singleton et la résolution transitoire: un singleton est là où vous enregistrez une instance d'une classe, par exemple. (en utilisant Unity):

container.RegisterInstance<IMyType>(new ConcreteMyType());

et cette instance est renvoyée à chaque fois (ce qui est assez rapide).

Un transitoire est l'endroit où vous n'enregistrez que le type de classe et l'infrastructure IoC se chargera de le créer pour vous, par exemple. (en unité)

container.RegisterType<IMyType, ConcreteMyType>();

Cela prend plus de temps que de retourner un singleton.

En termes d’optimisation globale, les frais généraux liés à l’injection de dépendance correspondent à une petite bière; d’autres goulots d’étranglement liés aux performances risquent d’être optimisés.

Answer 4

L'injection de dépendance en soi n'est qu'un simple indirection, il y a donc une surcharge mais c'est plutôt mineur. La correspondance et la résolution des modèles d'exécution est une autre chose (mais bien que souvent utilisé avec Dependency Injection, ce n'est pas comme si DI exige de tels extras; -).

Answer 5

L'injection de dépendance ne va pas engendrer d'énormes frais généraux. Je suis sûr que vous trouverez un goulot d'étranglement ailleurs. Si vous êtes tellement préoccupé par les frais généraux, c # n'est peut-être pas le langage que vous souhaitez utiliser. Vous utilisez C # pour les avantages qu’il apporte, il résume certains détails que vous ne voulez pas traiter.

Comme avec DI, cela présente également des avantages tels que l’application de votre application faiblement couplée, ce qui signifie qu’il sera plus facile pour vous de la conserver à l’avenir.

Answer 6

Frais généraux vs code testable et maintenable ... Je choisis un code testable et maintenable (vous pouvez toujours acheter un ordinateur plus rapide)

=)