|
|
Posted on 9/14/2018 1:22:21 PM
|
|
|
|
The instance scope determines how services are shared between requests.
Original address:http://docs.autofac.org/en/latest/lifetime/instance-scope.html
One instance per dependency
With this option, a new instance is returned each time the service is requested. Use InstancePerDependency(). This is the default option. The code below, lines 2 and 3 are equivalent.
The following code generates a new instance for each loop, for a total of 100 instances.
Single instance
Use this option to request a service in either the root or nested scope, both returning the same instance. Use SingleInstance() to specify.
The code below, w1 and w2 are always the same object, and there is only one instance of the Worker class in 100 loops.
One instance per lifecycle scope
Use this option to request a service in a specific ILifetimeScope, returning only one instance. Use InstancePerLifetimeScope(). In the following code, the 100 times w1 in scope1 is the same object, and the 100 times w2 in scope2 are the same object, but w1 and w2 are not the same object.
One instance per matching lifecycle range
Similar to [one instance per lifecycle scope] above, but with more control. Use this option to allow the ILifetimeScope object to be provided with a Tag. There is only one instance in the range of the tag match. Use the InstancePerMatchingLifetimeScope() method.
In the code below, w1 and w2 are the same, w3 and w4 are the same, but w1 and w3 are different.
The appropriate markup must be provided when parsing, and the following code throws an exception.
One instance per request
Some applications naturally have Request semantics, such as ASP.NET MVC or WebForm applications. [One instance per request] is implemented on the basis of [one instance per matching lifecycle range], by providing scope markers, registration functions, and common type integration. Essentially, [one instance per matching lifecycle range].
ASP.NET Core uses one instance per lifecycle scope instead of one instance per request.
One instance per Owned
The Owned<T> implicit association type creates nested lifecycle ranges. With instance-per-owned registration, you can limit dependencies to owned instances.
In this case, the ServiceForHandler service is limited to the scope of the MessageHandler instance.
Thread range
Autofac can force the objects of thread A to not satisfy the dependencies of thread B.
Then let each create their own lifetime scope
Important: In a multithreaded scenario, be careful not to clean up the parent scope.Otherwise, the subscopes in the derived thread will not be able to resolve the service.
Each thread will have its own instance of MyThreadScopedComponent, which is essentially a lifecycle-scoped singleton. Instances in scope are not provided externally, so it's easy to keep components isolated between threads.
By adding the ILifetimeScope parameter, the parent range can be injected into the code that generates the thread, and Autofac will automatically inject the current range, which can then be used to create nested scopes.
If you want to control it further, you can use [one instance per matching lifecycle range] to associate thread-scoped components with internal lifecycle scopes, as shown in the figure:
The "Context" in the diagram is the lifecycle range created by the BeginLifetimeScope method.
|
Previous:Front-end mouse click effects: freedom, democracy, prosperityNext:{"error_msg": "IAM Certification failed"}
|
