|
|
Publié sur 14/09/2018 13:22:21
|
|
|
|
La portée de l’instance détermine comment les services sont partagés entre les requêtes.
Adresse originale :http://docs.autofac.org/en/latest/lifetime/instance-scope.html
Une instance par dépendance
Avec cette option, une nouvelle instance est renvoyée à chaque demande du service. Utilisez InstancePerDependency(). C’est l’option par défaut. Le code ci-dessous, lignes 2 et 3, est équivalent.
Le code suivant génère une nouvelle instance pour chaque boucle, pour un total de 100 instances.
Instance unique
Utilisez cette option pour demander un service soit dans le scope root, soit dans le scope imbriqué, tous deux retournant la même instance. Utilisez SingleInstance() pour spécifier.
Le code ci-dessous, w1 et w2 est toujours le même objet, et il n’y a qu’une seule instance de la classe Worker dans 100 boucles.
Une instance par périmètre du cycle de vie
Utilisez cette option pour demander un service dans un ILifetimeScope spécifique, en ne retournant qu’une seule instance. Utilisez InstancePerLifetimeScope(). Dans le code suivant, les 100 fois w1 dans le champ de portée 1 correspondent au même objet, et les 100 fois fois w2 dans le champ de contrôle2 sont le même objet, mais w1 et w2 ne sont pas le même objet.
Une instance par plage de cycle de vie correspondante
Similaire à [une instance par portée de cycle de vie] ci-dessus, mais avec plus de contrôle. Utilisez cette option pour permettre à l’objet ILifetimeScope d’être doté d’un Tag. Il n’y a qu’une seule instance dans la plage du match par équipe. Utilisez la méthode InstancePerMatchingLifetimeScope().
Dans le code ci-dessous, w1 et w2 sont identiques, w3 et w4 sont identiques, mais w1 et w3 sont différents.
Le balisage approprié doit être fourni lors de l’analyse, et le code suivant lance une exception.
Une instance par requête
Certaines applications ont naturellement une sémantique de requête, comme ASP.NET MVC ou WebForm. [Une instance par requête] est implémentée sur la base de [une instance par plage de cycle de vie correspondante], en fournissant des marqueurs de périmètre, des fonctions d’enregistrement et une intégration de types communs. Essentiellement, [une instance par plage de cycle de vie correspondante].
ASP.NET Core utilise une instance par portée de cycle de vie au lieu d’une instance par requête.
Une instance par Possédé
Le<T> type d’association implicite Possédé crée des plages de cycle de vie imbriquées. Avec l’enregistrement instance par propriété, vous pouvez limiter les dépendances aux instances possédées.
Dans ce cas, le service ServiceForHandler est limité à la portée de l’instance MessageHandler.
Gamme de filets
Autofac peut forcer les objets du thread A à ne pas satisfaire les dépendances du thread B.
Puis laissez chacun créer sa propre portée de vie
Important : dans un scénario multithread, faites attention à ne pas nettoyer le scope parent.Sinon, les sous-scopes du thread dérivé ne pourront pas résoudre le service.
Chaque thread aura sa propre instance de MyThreadScopedComponent, qui est essentiellement un singleton à portée de cycle de vie. Les instances dans le scope ne sont pas fournies en externe, il est donc facile de garder les composants isolés entre les threads.
En ajoutant le paramètre ILifetimeScope, la plage parente peut être injectée dans le code qui génère le thread, et Autofac injecte automatiquement la plage actuelle, qui pourra ensuite être utilisée pour créer des scopes imbriqués.
Si vous souhaitez le contrôler davantage, vous pouvez utiliser [une instance par plage de cycle de vie correspondante] pour associer des composants à scope de thread avec des scopes de cycle de vie internes, comme montré sur la figure :
Le « Contexte » dans le diagramme correspond à la plage de cycle de vie créée par la méthode BeginLifetimeScope.
|
Précédent:Effets de clics de souris en interface : liberté, démocratie, prospéritéProchain:{"error_msg » : « Échec de la certification IAM"}
|
