anchor.diff:  var logger = container.GetInstance<ILogger>();
   ----
   
  -WARNING: Attention, la méthode GetInstance<T> peut très bien accepter des types implémentés sans que cela ne pose de problèmes. Cependant en faisant ça il y a une rupture avec le principe SOLID d'inversion de dépendance. N'oubliez pas : Il faut dépendre des abstractions, pas des implémentations.
  -
  -Si une dépendance n'est pas définit et que l'ont souhaite la résoudre, l'instance de Container léve une Exception de configuration. Il peut y avoir des cas où l'ont ne sait pas si une liaison est établie entre un contrat et une implémentation. Dans ce cas il vaut mieux utiliser la méthode TryGetInstance<T> et tester si l'instance est retournée est null, c'est plus optimisé que de traiter le cas avec un bloc try catch :
  -
  -[source,csharp]
  -----
  -//Aucune implémentation de IDisposable n'est configurés actuellement
  +WARNING: Attention, la méthode GetInstance<T> peut très bien accepter des types implémentés sans que cela ne pose de problèmes. Cependant, en faisant cela il y a une rupture avec le principe SOLID d'inversion de dépendance. N'oubliez pas : il faut dépendre des abstractions, pas des implémentations.
  +
  +Si une dépendance n'est pas définie et que l'on souhaite la résoudre, l'instance de Container lève une exception de configuration. Il peut y avoir des cas où l'on ne sait pas si une liaison est établie entre un contrat et une implémentation. Dans ce cas il vaut mieux utiliser la méthode TryGetInstance<T> et tester si l'instance est retournée est null, c'est plus optimisé que de traiter le cas avec un bloc try catch :
  +
  +[source,csharp]
  +----
  +//Aucune implémentation de IDisposable n'est configurées actuellement
   var disposable = container.GetInstance<IDisposable>();
   Console.WriteLine(disposable == null);//print True
   ----
   
  -La méthode Add<T> permettant de définir plusieurs implémentation d'un même contrat, il existe une méthode GetAllInstances<T>() qui renvoie l'ensemble des implémentations correspondante. Si on rajoute une nouvelle implémentation de ILogger :
  +La méthode Add<T> permettant de définir plusieurs implémentations d'un même contrat, il existe une méthode GetAllInstances<T>() qui renvoie l'ensemble des implémentations correspondante. Si on rajoute une nouvelle implémentation de ILogger :
   
   [source,csharp]
   ----
  
positive.code: Console.WriteLine(logger == logger2);//print True
  ----
  
  Ces deux cas sont parmis les principaux que l'ont trouve dans le développement mais il en existe d'autre qui permettent de gérer la vie de l'instance sur un Thread ou encore dans un container encapsuler dans un scope temporaire (ContainerScoped, utiliser pour gérer notamment le cas de DNX).
  
  Il existe une autre façon de déclarer un cycle de vie avec StructureMap. Dans la bibliothèque une interface ILifecycle permet d'implémenter facilement sont propre cycle de vie. Il est ensuite possible de l'utiliser dans la configuration avec la méthode LifecycleIs<T> (ou T implémente ILifecycle).
  
  WARNING: Les cycles de vies personnalisés peuvent être utilsé dans bien des cas. Il existe des bibliothèques qui fournissent des cycles spécialisés, comme pour le Web par exemple. Avec la version 4 de StructureMap l'équipe de développement encouragement fortement a ne plus utilisé se mode fonctionnement mais à préférer l'utilisation du NestedContainer à la place. Il permette de repondre à 95% des cas de figures sans avoir besoin de librairie annexe ni de code supplémentaire.
  
  Comme indiquer dans la note au dessus les NestedContainer permette aussi de gérer le cycle de vie des instances. En les utilisant on se simplifie clairement la vie car à partir du moment ou le NestedContainer est récupérer tout les instances qui sont obtenues lui sont propre. Il suffit ensuite d'appeller la méthode Dispose pour le libérer. C'est une méthode très fléxible puisqu'elle suffit d'établir un scope pour que cela fonctionne. En plus dans ce mode toutes les dépendances qui implemente IDisposable sont Dispose lors de l'appel à la méthode sur le NestedContainer. Du coup les trois états de StructureMap suffisent à gérer tous les cas, y compris ceux liée au context Web. Pour illustrer cela un Scope simple peut être imaginé : L'éxecution d'une ligne de code. Dans ce cas voici les étapes qui va falloir faire pour le mettre en place :
  
  * Le NestedContainer est crée et démarrer le Scope
  * Le code voulut est executé
  * Le NestedContainer libère les dépendances.
  
  Ces trois étapes peuvent bien évidement être rejouer à l'infinit. Pour illustrer le bon fonctionnement du Dispose, un implémentation de ILogger disposable va être utilisé :
  
  [source,csharp]
  ----
  
negative.code: }
  ----
  
  Par défaut StructureMap ne résoudra pas la dépendance en l'état. Dans la configuration il faut, lors de la liaison entre un contrat et son implémentation, utiliser la méthode Setter pour spécifier le type de dépendance sous jacente qui va être injecté : 
  
  [source,csharp]
  ----
  