La manière dont les instances d'un service sont partagées antre différentes requêtes est déterminée par leur cycle de vie. Lorsque vous demandez un service au conteneur Autofac, celui-ci peut retourner une instance unique (singleton), un nouvel objet (par dépendance), ou une instance unique au sein d'un contexte spécifique, comme un thread ou une requête HTTP.

Ces règles s'appliquent aussi bien lorsque vous récupérez explicitement un objet via Resolve que lorsuq'il est résolu implicitement pour satisfaire une dépendance.

1. InstancePerDependency

Également connu sous le nom de transient ou factory dans d'autres conteneurs, ce cycle de vie garantit qu'une nouvelle instance du composant est créée à chaque fois qu'il est demandé. C'est le comportement par défaut si aucun autre cycle de vie n'est spécifié.

builder.RegisterType<Worker>();

// Ou explicitement : builder.RegisterType<Worker>().InstancePerDependency();

</div>### 2. `SingleInstance`

Avec le cycle de vie `SingleInstance`, Autofac s'assure qu'une seule instance du composant est créée pour l'ensemble du conteneur parent et de tous les conteneurs enfants. Cette instance est réutilisée pour toutes les requêtes.

<div>```

builder.RegisterType<Worker>().SingleInstance();

Ce cycle de vie est particulièrement utile pour les scénarios impliquant des portées de vie imbriquées. Un composant enregistré avec InstancePerLifetimeScope n'aura qu'une seule instance par portée de vie imbriquée. C'est idéal lorsque vous avez besoin d'une instance unique pour une unité de travail spécifique, comme une requête HTTP. Si vous créez une portée de vie imbriquée pour chaque requête HTTP, tous les composants marqués InstancePerLifetimeScope n'auront alors qu'une seule instance par requête.

Cette configuration est l'équivalent de per-HTTP-request ou per-thread dans d'autres systèmes d'injection de dépendances.

builder.RegisterType<Worker>().InstancePerLifetimeScope();

</div>Dans les intégrations avec ASP.NET et WCF, le cycle de vie `InstancePerLifetimeScope` est appliqué par défaut à vos composants pour chaque requête web ou appel de méthode.

### 4. `InstancePerMatchingLifetimeScope` (Utilisation de tags)

Ce type de portée est similaire à `InstancePerLifetimeScope` mais offre un contrôle plus granulaire sur la visibilité des instances. Dans la plupart des applications, les portées de vie imbriquées représentent des unités de travail. Si votre application utilise plusieurs niveaux d'imbrication (par exemple, globale &gt; session utilisateur &gt; transaction), vous pouvez utiliser des "tags" pour vous assurer qu'un composant est partagé uniquement à un niveau spécifique de cette hiérarchie.

<div>```

// Enregistrement du composant avec un tag spécifique
builder.RegisterType<XWorker>().InstancePerMatchingLifetimeScope("NomSessionUtilisateur");

// Création d'une portée de vie avec ce tag
var userSessionScope = container.BeginLifetimeScope("NomSessionUtilisateur");