前面的几个篇幅对Web API中的路由和管道进行了简单的介绍并无详细的去说明一些什么,然而ASP.NET Web API这个框架因为宿主环境的不一样在不一样的宿主环境中管道中的实现机制和路由的处理方式有着很大的不一样,因此我会将对应不一样的宿主环境来分别的作出简单的讲解。web
首先咱们先来看个示意图,大概的描述了在SelfHost宿主环境中管道形态。框架
图1ide
由于在WebHost宿主环境中ASP.NET Web API的管道请求接收以及响应的返回最后都是由ASP.NET来包办的(下一篇中讲解),而在SelfHost宿主环境中就苦逼了,没有那么简单了。函数
咱们按照图1中示意的来说解,首先在SelfHost宿主环境中的项目启动以后(固然项目要使用Web API框架的),会有一个HttpBinding对象(System.Web.Http.SelfHost.Channels),那这个HttpBinding类型的对象是干吗的呢?Httpbinding对象对应着一些个BindingElement对象,而这些BindingElement又各自生成对应的管道层监听器,这样就如图1中所示的那样,如今咱们看一下以下的示例代码,看看HttpBinding到底对应着哪些BindingElement对象。this
示例代码1-1spa
public class HttpBinding : Binding, IBindingRuntimePreferences { public HttpBinding() { this.Initialize(); } private void Initialize() { this._security = new HttpBindingSecurity(); this._httpTransportBindingElement = new HttpTransportBindingElement(); this._httpTransportBindingElement.ManualAddressing = true; this._httpsTransportBindingElement = new HttpsTransportBindingElement(); this._httpsTransportBindingElement.ManualAddressing = true; this._httpMessageEncodingBindingElement = new HttpMessageEncodingBindingElement(); } }
在示例代码1-1中咱们能够清楚的看到在HttpBinding对象的构造函数中分别的对几种BindingElement进行了实例化赋值,咱们只对其中的HttpTransportBindingElement和HttpMessageEncodingBindingElement进行讲解也就是图1中所示的那样。code
HttpTransportBindingElement对象的主要职责就是生成相对应的管道监听器,这里对应的就是IChannelListener<TChannel>泛型类型了,而生成好对应的管道监听器以后,监听器以后会开始监听与之对应的管道层,与HttpTransportBindingElement对象以及监听器对应的也就是TransprotChannel管道层了,它负责请求消息的接收和响应消息的发送。orm
HttpMessageEncodingBindingElement类型的对象所作操做同HttpTransportBindingElement类型一致,都是先要生成对应的管道监听器,在这里与之对应的就是HttpMessageEncodingChannelListener类型,在监听器生成好以后也会去监听对应的EncodingChannel管道层,而EncodingChannel管道层主要的做用就是将请求信息封装为HttpMessage类型的消息对象,以后由HttpMessage消息对象进入ASP.NET Web API框架的管道系统中。对象
上面说的是在请求未到达ASP.NET Web API框架的管道系统中的时候在外部的一些处理和操做,下面咱们就要说明一下内部,在上篇的《ASP.NET Web API 管道模型》篇幅中有示例代码演示过在SelfHost环境下管道的注册,咱们这里看一下在SelfHost环境中Web API框架自身的管道系统里的对象的一些类型。blog
HttpSelfHostServer消息处理程序(实现类-管道头)System.Web.Http.SelfHost
public sealed class HttpSelfHostServer : HttpServer { public HttpSelfHostServer(HttpSelfHostConfiguration configuration); public HttpSelfHostServer(HttpSelfHostConfiguration configuration, HttpMessageHandler dispatcher); public Task CloseAsync(); protected override void Dispose(bool disposing); public Task OpenAsync(); }
能够看到HttpSelfHostServer类型继承自HttpServer,在上篇中咱们也就提到过HttpServer是继承自DelegatingHandler抽象类型的消息处理程序基类,DelegatingHandler与HttpMessageHandler的不一样之处就是多了个指向下一个处理程序的引用,固然了做为一个管道系统中第一个消息处理程序必须是要有指向下一个处理程序引用的这么一个标识,这样是合理的。咱们再看HttpSelfHostServer类型的构造函数的参数类型。
HttpSelfHostConfiguration类型是继承自HttpConfiguration类型的,在上篇中咱们也说过,HttpConfiguration中能够配置管道中的大多数信息,这个你们能够本身去看一下。在重载构造函数中有了第二个构造函数参数,HttpMessageHandler类型的参数,在默认使用HttpSelfHostServer的时候假使不使用这个重载的构造函数,那么在HttpSelfHostServer实例化的以前先实例化以前,其基类HttpServer的构造函数开始执行,因此在看下HttpServer类型的构造函数的时候咱们能够看到这里默认设置的HttpMessageHandler类型的参数究竟是什么样子的。
public HttpServer() : this(new HttpConfiguration()) { } public HttpServer(HttpMessageHandler dispatcher) : this(new HttpConfiguration(), dispatcher) { } public HttpServer(HttpConfiguration configuration) : this(configuration, new HttpRoutingDispatcher(configuration)) { } public HttpServer(HttpConfiguration configuration, HttpMessageHandler dispatcher) { this._initializationLock = new object(); if (configuration == null) { throw System.Web.Http.Error.ArgumentNull("configuration"); } if (dispatcher == null) { throw System.Web.Http.Error.ArgumentNull("dispatcher"); } this._dispatcher = dispatcher; this._configuration = configuration; }
这里你们能够清楚的看到是HttpRoutingDispatcher类型做为管道的最后一个处理程序的类型,对于这个类型以及详细的信息,在下面的路由小节中会有说明。
对于路由的其余知识这里就不说了,就是简要的提一下在SelfHost中路由、管道的一些细节。
图2
这里要详细说明的就是HttpRoutingDispatcher类型中的SendAsync()方法,看下源码中的实现这样更清楚。
public class HttpRoutingDispatcher : HttpMessageHandler { // Fields private readonly HttpConfiguration _configuration; private readonly HttpMessageInvoker _defaultInvoker; // Methods public HttpRoutingDispatcher(HttpConfiguration configuration) : this(configuration, new HttpControllerDispatcher(configuration)) { } protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) { IHttpRouteData routeData; if (!request.Properties.TryGetValue<IHttpRouteData>(HttpPropertyKeys.HttpRouteDataKey, out routeData)) { routeData = this._configuration.Routes.GetRouteData(request); if (routeData == null) { return TaskHelpers.FromResult<HttpResponseMessage>(request.CreateErrorResponse(HttpStatusCode.NotFound, Error.Format(SRResources.ResourceNotFound, new object[] { request.RequestUri }), SRResources.NoRouteData)); } request.Properties.Add(HttpPropertyKeys.HttpRouteDataKey, routeData); } RemoveOptionalRoutingParameters(routeData.Values); HttpMessageInvoker invoker = (routeData.Route.Handler == null) ? this._defaultInvoker : new HttpMessageInvoker(routeData.Route.Handler, false); return invoker.SendAsync(request, cancellationToken); } }
咱们先看一下HttpRoutingDispatcher类型中构造函数,能够看到在定义的构造函数后面紧接着又在实例基类的构造函数,而且第二个HttpMessageHandler类型的参数为HttpControllerDispatcher实例的对象,这个咱们先记住就好了。
下面咱们仍是回到HttpRoutingDispatcher类型的SendAsync()方法中,首先咱们会看到从HttpRequestMessage对象实例的Properties属性集合中获取路由数据对象。
在SelfHost的环境下这是获取不到的,为啥?由于上面以及以前的篇幅中在管道的处理中没有提到过处理路由而且生成路由数据的。因此这个时候会根据HttpConfiguration中的HttpRouteCollection类型的属性Routes,Routes属性再根据SendAsync()方法的参数类型为HttpRequestMessage的request信息获取路由数据对象IHttpRouteData。
在匹配成功获取到路由数据对象(IHttpRouteData)以后便会添加至HttpRequestMessage对象实例(request)的Properties属性集合中。
以前对于路由的了解,最后的执行的Handler都是起初定义在路由对象中的,而在实际状况中,咱们注册路由的时候并无,假使这种状况就在如今发生,能够看到routeData.Route.Hander==null这个是成立的,因此执行的是咱们先前说过的在构造函数中的HttpControllerDispatcher类型的实例的SendAsync()方法(实际当中HttpControllerDispatcher类型被HttpMessageInvoker类型所封装)。
而HttpControllerDispatcher类型就跟Web API控制器有关了,这里就不提早说了,后面必定会讲到。
做者:金源
出处:http://www.cnblogs.com/jin-yuan/
本文版权归做者和博客园共有,欢迎转载,但未经做者赞成必须保留此段声明,且在文章页面