[Dot Net Core](Graphic series )10. The easiest way to verify the feature of Resolved Singleton objects in the architecture
In the previous section, through the description, we saw that the controller class is in the process of being generated instance, in which IActionInvokerFactory will be Resolved into ActionInvokerFactory instance. At this time, the parameter objects in the constructor will continue to be resolved into instance through the DI mechanism.
In the “UseEndpoint to Map Controller” section, in fact, the output of this instance of ApplicationPartManager is because its identity is the constructor parameter object of ControllerActionDescriptorProvider. When Resolved, the ApplicationParts collection of the ApplicationPartManager already contains the component information to which the Controller Class belongs.
Review the diagram below in the “UseEndpoint to Map Controller” section:
But what is curious is that there is no code to add the content of the ApplicationParts collection of ApplicationPartManager in the constructor, but why does the object that was just constructed already have value in this collection?
The reason is that it has been Resolved before this time point, and the form of Resolve is Singleton; and the component information is packaged into the ApplicationPartManager.ApplicationParts collection through ApplicationPartManager.PopulateDefaultParts for subsequent further retrieval of Controller and Action information. The exact point in time will be described in the next section.
We can make a simple Resolve Singleton object in the Dot Net Core architecture to prove that its memory location and content can be saved until the next Resolve (still a Singleton instance).
There are several steps:
Step1: Create a simple class TestClass, as follows:
Step2: Add a static field IApplicationBuilder AppBuilder in the Startup category, register this class in the ConfigureServices function; Resolve TestClass in the Configure function, and add a DateTime string to the TestClass.ListStringCollection string collection. Then assign the entity of IapplicationBuilder to Startup.AppBuilder.
as follows:
Step3: Execute the project and observe Startup.Configure, use the serviceProviderEngineScope of AppBuilder to do the Resolve Service of the IOC, the memory location of the TestClass that is resolved and its member content.
Step4: Request to Controller Action (Default Controller “WeatherForecastController”)
Step5: When the Action of the Controller is observed, whether the TestClass that is Resolved again has the same memory location and the string content stored in the ListStringCollection string collection as before.
As shown in the figure above, when the TestClass is finally Resolved, no changes are made to the contents of its members, and the constructor does not change the contents of the members as in the first picture; the memory location and the contents of the strings stored in the ListStringCollection string collection are both Consistent with the time string specified in Startup.Configure.
In Startup.ConfigureServices, if the instance is generated and the content is set before registering the service, the same result can be obtained. The way is as follows:
Therefore, through the above proof, once the instance of Singleton is Resolved, the memory location will be preserved. Similarly, it can be explained that when the Resolve Controller Class is processed, the ApplicationPartManager Class already contains the component information where the Controller is located when it is Resolved during the execution of the endpoint middleware phase. It will be explained in detail in the next section.
