Talking about the instance scope of the AUTOFAC component _c# Tutorial

The scope of an instance determines how services are shared between requests.

Original address: http://docs.autofac.org/en/latest/lifetime/instance-scope.html

Each dependent one instance
with this option, each request service will return a new instance. Specified using Instanceperdependency (). This is the default option. The following code, lines 2nd and 3rd are equivalent.

var builder = new Containerbuilder ();
Builder. Registertype<worker> ();
Builder. Registertype<worker> (). Instanceperdependency ();

The following code generates a new instance of each loop, generating 100 instances altogether.

using (var scope = container. Beginlifetimescope ())
{for
 (var i = 0; i < i++)
 {
  var w = scope. Resolve<worker> ();
  W.dowork ();
 }

Single Instance

Use this option to request a service in the root range or nested scope, returning the same instance. Specified using SingleInstance ().

var builder = new Containerbuilder ();
Builder. Registertype<worker> (). SingleInstance ();
The following code, W1 and W2 are always the same object, 100 cycles have only one instance of the Worker class.

using (var scope1 = container. Beginlifetimescope ())
{for
 (var i = 0; i < i++)
 {
  var w1 = scope1. Resolve<worker> ();
  using (var scope2 = scope1. Beginlifetimescope ())
  {
   var w2 = scope2. Resolve<worker> ();}}

One instance per life cycle scope

With this option, the service is requested in a specific ilifetimescope and only one instance is returned. Specified using Instanceperlifetimescope (). In the following code, the 100 w1 in Scope1 are the same object, Scope2 100 w2 are the same object, but W1 and W2 are not the same object.

var builder = new Containerbuilder ();
Builder. Registertype<worker> (). Instanceperlifetimescope ();
using (var scope1 = container. Beginlifetimescope ())
{for
 (var i = 0; i < i++)
 {
  var w1 = scope1. Resolve<worker> ();
 }

using (var scope2 = container. Beginlifetimescope ())
{for
 (var i = 0; i < i++)
 {
  var w2 = scope2. Resolve<worker> ();
 }

One instance of each matching life cycle scope

Similar to "one instance per lifecycle range" above, but can provide more control. Use this option to allow tokens to be provided for Ilifetimescope objects. There is only one instance in the range where the tag matches. Specified using the Instancepermatchinglifetimescope () method.

var builder = new Containerbuilder ();
Builder. Registertype<worker> (). Instancepermatchinglifetimescope ("X");

In the following code, W1 and W2 are the same, W3 and W4 are the same, but W1 and W3 are different.

using (var scope1 = container. Beginlifetimescope ("x"))
{for
 (var i = 0; i < i++)
 {
  var w1 = scope1. Resolve<worker> ();
  using (var scope2 = scope1. Beginlifetimescope ())
  {
   var w2 = scope2. Resolve<worker> ();

}} using (var scope3 = container. Beginlifetimescope ("x"))
{for
 (var i = 0; i < i++)
 {
  var W3 = scope3. Resolve<worker> ();
  using (var scope4 = scope1. Beginlifetimescope ())
  {
   var W4 = scope4. Resolve<worker> ();}}

The following code throws an exception when parsing must provide the appropriate markup.

using (var Notagscope = container. Beginlifetimescope ())
{
 var fail = notagscope.resolve<worker> ();
}

One instance per request

Some applications have a natural "request" semantics, such as ASP.net MVC or webform applications. "Each request one instance" is based on "one instance of each matching lifecycle scope" by providing a scope tag, registration functions, and common type integration implementations. is essentially "one instance of each matching lifecycle range."

var builder = new Containerbuilder ();
Builder. Registertype<worker> (). Instanceperrequest ();

asp.net Core uses "one instance per lifecycle range" instead of "one instance per request".

One instance per owned

Owned<t> An implicit association type creates a nested lifecycle scope. With instance-per-owned registration, you can qualify dependencies in the owned instance.

var builder = new Containerbuilder ();
Builder. Registertype<messagehandler> ();
Builder. Registertype<serviceforhandler> (). Instanceperowned<messagehandler> ();

In this case, the Serviceforhandler service is limited to the MessageHandler instance scope.

using (var scope = container. Beginlifetimescope ())
{
 //MessageHandler and attached serviceforhandler 
 //In a miniature lifetime scope below scope.
 //parsing owned<t> requires programmers to perform cleanup work.
 var h1 = scope. Resolve<owned<messagehandler>> ();
 H1. Dispose ();
}

Thread Range

AUTOFAC can force the object of a thread to not satisfy the B-thread dependency.

var builder = new Containerbuilder ();
Builder. Registertype<mythreadscopedcomponent> ()
    . Instanceperlifetimescope ();
var container = Builder. Build ();

And then let each create your own lifetime scope

void ThreadStart ()
{
 using (var threadlifetime = container. Beginlifetimescope ())
 {
  var thisthreadsinstance = threadlifetime.resolve<mythreadscopedcomponent> ( );
 }
}

Important: in a multithreaded scenario, be careful not to clean out the parent range. Otherwise, the child scopes in the derived thread will not be able to resolve the service.

Each thread will have its own mythreadscopedcomponent instance, which is essentially a singleton within the life cycle scope. The instances within the scope are not provided externally, so it is easy to keep component isolation between threads.

By adding the Ilifetimescope parameter, the parent scope can be injected into the code of the build thread, and AUTOFAC will automatically inject the current scope, which can then be used to create nested scopes.

public class Threadcreator
{
 private ilifetimescope _parentscope;

 Public Threadcreator (Ilifetimescope parentscope)
 {
  this._parentscope = parentscope;
 }

 public void ThreadStart ()
 {
  using (var threadlifetime = This._parentscope.beginlifetimescope ())
  {
   var thisthreadsinstance = threadlifetime.resolve<mythreadscopedcomponent> ();}}}

If you want further control, you can associate a thread-scoped component with an internal lifecycle scope by using an instance of each matching lifecycle scope, as shown in the following example:

The "context" in the diagram is the life cycle scope created by the Beginlifetimescope method.

The above is the entire content of this article, I hope to help you learn, but also hope that we support the cloud habitat community.