How is ASP. NET Web API Controller Built?

How is ASP. NET Web API Controller Built?
The Message pipeline architecture consists of three layers: Hosting, Message Handlers, and Controller ). The red and solid arrows in the figure represent HTTP request messages, and the dotted arrows represent HTTP response messages. The message processing process is as follows: when the client sends an HTTP request to the server, it begins to enter ASP. NET Web API framework, the HTTP request message is encapsulated into an HttpRequestMessage object and enters the HttpServer (web load) or HttpSelfHostServer (self-load) of the "LOAD" block at the top of the figure ). Then, the message enters the next stage of the pipeline until the entire message process is completed, an HttpResponseMessage object representing the HTTP Response Message is obtained, and the message content of this object is sent back to the client. The HttpRequestMessage object enters the message processing program pipeline. In this phase, the HTTP message is transmitted through several message handlers and executed in reverse order when an HTTP Response message is returned. After each message processing program, the HTTP request message is then passed to HttpControllerDispatcher, and this object is used to establish the Web API controller, then, the HTTP request is sent to the controller object (the "(A) create controller" step is shown in the figure ). The Controller will first determine the target action method (that is, the steps marked "(B) Select action" in the figure) and then call it. The action method will generate the response content, and then return along the reverse direction of the aforementioned pipeline process. The above is the general processing process of the Web api http message pipeline. How is Web API Controller Built? Just now, I only explained the general processing process of the Web API HTTP message pipeline. to inject the dependent object into the controller class, or to change the default behavior, you must understand the internal process of building a controller in the Web API framework. This section further describes the complex links. Multiple abstract interfaces are repeatedly mentioned in this section. It may be difficult for you to read them for the first time, and you may be confused, however, when I have actually written and ran the subsequent sample program, and then I will look back at the description in this section, the entire puzzle will become clearer. As mentioned earlier, HttpControllerDispatcher will establish the target controller object, that is, the steps for marking "(A) create controller" in the previous ASP. NET Web API pipeline architecture diagram. This step actually involves two tasks: parsing the target controller. That is, determine the type of controller to use. Create an instance of the Target controller class, and pass the HTTP request (HttpRequestMessage object) to it for later processing by the controller. First, the "Resolution target controller" mainly aims to find all available controller categories from the DLL components of the application, and then select a matching HTTP request. The processing logic is shown in: Note: The getassembliesresolver method of the iassemblies object below the figure provides a list of application components, and the getcontrollertyperesolver method of the ihttpcontrollertypes object obtains the list of available controller categories. IHttpControllerSelector is responsible for deciding which controller category to select, and then returning an HttpControllerDescriptor object containing its type information to HttpControllerDispatcher. From determining the target controller type to establishing a controller instance, there are also some expansion points provided by core standard interfaces. The following uses a UML activity diagram with the original Web API code to deconstruct its internal processing process. Description: (1) HttpControllerDispatcher obtains the target controller type information through the SelectController method of the IHttpControllerSelector object. The type information is contained in an HttpControllerDescriptor object. (2) HttpControllerDispatcher calls the CreateController method of the HttpControllerDescriptor object, which calls the GetHttpControllerActivator method of the ServicesContainer object to obtain the IHttpControllerActivator object. The following program snippets are taken from the original Web API code and cover part of the logic from this step to the next step: copy the code // CreateController method of the HttpControllerDescriptor class. Public virtual IHttpController CreateController (HttpRequestMessage request) {IHttpControllerActivator activator = Configuration. services. getHttpControllerActivator (); IHttpController instance = activator. create (request, this, ControllerType); return instance;} copy the code (3) to obtain the IHttpControllerActivator object, and then call its Create method. this method calls its own getinstanceeffectivator method, to obtain the controller instance. The following program snippet is taken from the original code of the DefaultHttpControllerActivator category. I removed the error handling and cache part and added a Chinese annotation: copy the code // Create ulthttpcontrolleractivator to Create a public IHttpController Create (HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType) {Func <IHttpController> activator; IHttpController controller = GetInstanceOrActivator (request, controllerType, out activator); if (controller! = Null) {// The dependency resolver to the Web API framework. // The controller-type independent response has been created. Return controller; // you can directly use this object.} // The Target controller object has not yet created return activator (); // use the GetInstanceOrActivator method to initiate a delegation to create an object} copy the code (4) the getinstanceeffectivator method of the IHttpControllerActivator object calls the extended HttpRequestMessage method GetDependencyScope to obtain the IDependencyScope object associated with the current request (actually a Service Locator) and uses its GetService method to obtain the controller object. If the GetService method does not return the controller object, but returns null (which means that the service type cannot be resolved), the second step is to use the type reflection mechanism to establish the controller object. Similar to the original code: copy the code // from DefaultHttpControllerActivator. csprivate static IHttpController GetInstanceOrActivator (HttpRequestMessage request, Type controllerType, out Func <IHttpController> activator) {// If the dependency scope has a controller object, use it. IHttpController instance = (IHttpController) request. GetDependencyScope (). GetService (controllerType); if (instance! = Null) {activator = null; return instance;} // otherwise, create a delegate to create an instance of this type. Activator = TypeActivator. create <IHttpController> (controllerType); return null;} copy the request in the code. getDependencyScope () corresponds to the extended method GetDependencyScope of the call HttpRequestMessage to get the IDependencyScope object associated with the current request. 」 The actual IDependencyScope object obtained here is the preset implementation provided by the Web API framework: EmptyResolver. We can see from the category name that this category does not actually do anything -- its GetService method returns null. Therefore, by default, the Web API framework uses the type reflection mechanism to create a controller object, this is why our controller category must have a default constructor. In general, the controller object is built in this way.