anchor.diff:  convention.WithAnyTypeFromNamespaceContainingType<ILogger>();
   ----
   
  -Ces trois exemples de convention permettent de traiter pas mal de cas. La classe SetterConvention offre d'autres possibilités pour customiser sa logique d'injection. Le mieux c'est de les essayer pour voir celle qui conviennent aux besoins.
  -
  -Sans s'en rendre compte, en utilisant les conventions, une nouvelle capacité de Container a été dévérouillée, le BuildUp ! Il est maintenant possible de se dispenser d'utiliser la méthode GetInstance<T>() pour obtenir une instance d'un dépendant avec ses dépendances injectées :
  +Ces trois exemples de convention permettent de traiter pas mal de cas. La classe _SetterConvention_ offre d'autres possibilités pour customiser sa logique d'injection. Le mieux c'est de les essayer pour voir celle qui conviennent aux besoins.
  +
  +Sans s'en rendre compte, en utilisant les conventions, une nouvelle capacité du container a été dévérouillée, le _BuildUp_ ! Il est maintenant possible de se dispenser d'utiliser la méthode _GetInstance<T>()_ pour obtenir une instance d'un dépendant avec ses dépendances injectées :
   
   [source,csharp]
   ----
  
positive.code: container.BuildUp(controller);
  ----
  
  L'intérêt premier est qu'avec cette technique on va pouvoir injecter les dépendances d'une instance dont la création est faite par un tier. Mine de rien cela ouvre pas mal de possibilité et permet de s'interfacer avec d'autre Framework ou Api qui possède leur propre mécanique de création d'instance (On peut cité par exemple Asp.Net MVC avec les ControllerFactory). C'est aussi une façon de faire qui est plus proche de la théorie de l'inversion de contrôle car dans ce cas précis il n'y a plus aucun appel direct de résolution d'un dépendant, le Container se préoccupe de ce qu'il sait faire de mieux, résoudre les dépendances !
  
  Au niveau de la mécanique d'injection des dépendances nous avons vu les fondamentaux. Il faut savoir que la méthode priviliégiée par la plupart des développeurs est celle injectant les dépendances par constructeur. Elle demande bien moins d'effort et évite d'avoir des propriétés publiques accessibes par le premier venu. Cependant, il existe de nombreux cas où l'inspection par propriété est indispensable (par exemple pour injecter des dépendances dans des attributs), donc il ne faut pas non plus écarter cette possibilité. Personnellement j'utilise beaucoup l'injection par propriété, car cela permet d'avoir une grande compacité de code en plus d'éviter de manipuler l'affectation des références à la main (je trouve que c'est plus propre sur ce point). Cependant, quand je le fais je suis beaucoup plus stricte sur les règles de manipulation de ses instances. Il faut clairement que la responsabilité de leur manipulation soit faite uniquement par le dépendant, sinon c'est la porte ouverte à de nombreux problèmes.
  
  
  == Lifecycle
  
  Depuis le début de cet article la création des dépendances a été complétement délégué à la classe Container. La grande question à présent est : Comment puis gérer le cycle de vie des instances au sein d'une instance de Container ?
  
  StructureMap, comme tous les container IoC, met à disposition un ensemble de méthode et classe pour gérer cela. Par défaut lorsque l'on ajoute une liaison entre un contrat et une implémentation, le container va définir leur cycle de vie à l'état Transient. Cela veut dire qu'à chaque fois qu'il résoudra une dépendance il créera une instance. Il est tout à fait possible de mettre explicitement la dépendance dans le mode Transient :
  
  [source,csharp]
  ----
  
negative.code: configuration.For<ILogger>().Add<FileLogger>();
  ----
  
  L'appel à la méthode renverra une instance de _IEnumerable<ILogger>_ :
  
  [source,csharp]
  ----
  