anchor.diff:  }
   ----
   
  -Pour la configuration rien ne change à par l'appel à Use<T> qui utilise DisposableConsoleLogger  :
  +Pour la configuration rien ne change à par l'appel à _Use<T>_ qui utilise _DisposableConsoleLogger_  :
   
   [source,csharp]
   ----
  
positive.code: }
  ----
  
  Pour résoudre cette dépendance via le container il faut la définir. La classe possède un constructeur acceptant en paramètre une action qui expose un object de configuration. Il permet de définir les liaisons entre contrat et implémentation à l'aide des méthodes For<T> et Use<T> :
  
  [source,csharp]
  ----
  
negative.code: controller.Action();// print "Hello from action !"
  ----
  
  NOTE: J'en vois déjà qui vont me répondre que j'ai mis un *Warning* plus haut concernant l'appel de _GetInstance<T>_ sans utiliser une interface ! En réalité dans ce cas les choses sont différentes, car _Controller_ n'est pas une dépandance mais un dépendent. La résolution est donc conforme au principe d'inversion de dépendance. Cette manière de procéder est une des plus couramment utilisées dans le monde .Net (on l'a retrouve sous la forme de *Dependency Resolver* dans certaines frameworks Microsoft).
  
  StructureMap offre aussi la possibilité d'injecter les dépendances par *inspection* des propriétés plutôt que par le constructeur. C'est une alternative intéressante et facile à mettre en oeuvre. Déjà cela permet de réduire le code de la classe _Controller_ à :
  
  [source,csharp]
  ----
  