anchor.diff:  Console.WriteLine(loggers.Count() == 2);//print True
   ----
   
  -A ce stade vous avez les bases pour résoudre des dépendances. Cependant, l'utilisation actuelle du Container correspond à peu de choses prêt au pattern ServiceLocator. On aurait aussi pu faire une Factory pour gérer la création d'instance. Il est donc temps de s'intéresser à l'injection des dépendances.
  +A ce stade vous avez les bases pour résoudre des dépendances. Cependant, l'utilisation actuelle du container correspond à peu de choses prêt au pattern ServiceLocator. On aurait aussi pu faire une Factory pour gérer la création d'instance. Il est donc temps de s'intéresser à l'injection des dépendances.
   
   == Injection
   
  -Pour injecter les dépendances il nous faut une classse de plus haut niveau qui repose sur le contrat établit dans ILogger. Pour continuer avec un cas simple prenons l'exemple d'un contrôleur qui, lors de l'exécution d'une action, trace une information via le Logger. Si l'on veut casser l'adhérence il faut passer la dépendance implémentant ILogger via le constructeur :
  +Pour injecter les dépendances il nous faut une classse de plus haut niveau qui repose sur le contrat établit dans _ILogger_. Pour continuer avec un cas simple prenons l'exemple d'un contrôleur qui, lors de l'exécution d'une action, trace une information via le _Logger_. Si l'on veut casser l'adhérence il faut passer la dépendance implémentant _ILogger_ via le *constructeur* :
   
   [source,csharp]
   ----
  
positive.code: 
  Pour finir cet article, je vous propose un ensemble de règle qu'il est bon de suivre :
  
  * Masquer l'accès au Container : L'inversion de contrôle sert à casser les adhérances. Si vous utilisez spécifiquement un container pour résoudre des dépendances alors c'est l'inverse qui se produit. Il vaut donc mieux passer par une couche intermédiaire qui va vous permettre de changer le Container facileement si besoin.
  
  * Préfére l'injection par constructeur : Elle ne demande pas de logique d'injection et est par conséquent la manière la plus simple de la mettre en place !
  
  * N'oubliez pas l'injection par propriété : Certains cas ne sont pas possibles avec l'injection par constructeur, n'hésitez surtout pas à utiliser celle par propriété, elle est là pour ça !
  
  * Ne mélangez pas les cycles de vie : Beaucoup ont essayé et se sont cassés les dents. Mise à part le Singleton qui est simple à comprendre et mélanger pour le reste abstenez-vous. En mixant le risque c'est que plus le projet grossit plus la grappe de rétention entre les instances devient complexe. On peut vite arriver à des situations hors de contrôle.
  
  * N'injectez pas des types primitifs : Techniquement c'est faisable mais c'est une erreur. Les dépendants attendent des dépendances définies par des contrats, les types primitifs ne répondent pas cela.
  
  * Ne faites pas de résolution de dépendance base sur des chaines de charactère (Nom, Type, Namespace) : Ici encore techniquement c'est possible mais cela compléxifie la maintenance et oblige à revalider la configuration du Container à chaque renommage de dépendance, propriété, namespace. Au final vous allez perdre du temps et il y a d'autre façon de le faire bien plus efficace.
  
  * Inutile de définir des cycles de vie, il vaut mieux utilisé le Scoping : L'exemple des NestedContainer parle de lui-même :)
  
  * Ne mélangez pas IoC et Réflexion : C'est une fausse bonne idée. Se sont deux aspects bien différents qui peuvent parfois aboutir au même résultat, mais qui n'ont pas du tout la même vocation. Si vous faites de la réflexion pour activer des dépendances dans ce cas utilisez plutôt https://msdn.microsoft.com/fr-fr/library/dd460648(v=vs.110).aspx[MEF]  . Si se n'est pas le cas alors vous faites très certainement quelque chose qu'un container IoC fait déjà :)
  
  * Votre container ne devrait jamais être utilisé dans des tests unitaires
  
  * Les dépendances peuvent grossir en nombre rapidement. Pour mieux organiser leur configuration il existe dans StructureMap une classe appelée Registry. Cette classe permet de grouper la configuration par domaine de dépendance.
  
  * Avec l'inversion de contrôle la résolution des dépendances se fait au runtime. C'est donc l'application qui doit tenir les références. Inutile d'essayer de les masquer, vous ne gagnerez pas plus de temps ni de confort de développement !
  
  
  Voilà, j'espère que vous aurez apprécié la lecture de cet article. L'inversion de contrôle est un concept qui doit être connu, car de nombreux projets le mettent en oeuvre. StructureMap est un excellente bibliothèque. J'aurais aimé vous présenter toutes ses capacités mais elles sont tellement nombreuses qu'il faudrait plusieurs articles pour toutes les traiter !
  
negative.code: });
  ----
  
  Plusieurs possibilités sont offertes pour définir une convention. La plus simple est celle qui exige un type stricte :
  
  [source,csharp]
  ----
  