Web API之消息处理管道
标签:
Web API之消息处理管道 前言MVC有一套请求处理的机制,当然Web API也有自己的一套消息处理管道,该消息处理管道贯穿始终都是通过HttpMessageHandler来完成。我们知道请求信息存在 RequestMessage 中,而响应信息则存在 ResponseMessage 中,当请求信息进入到管道中,此时HttpMessageHandler会对此进行相应的处理,当执行到控制器上的方法时此时就会进行响应,生成的响应信息HttpResponseMessage就会逆向通过HttpMessageHandler依次进行处理最终返回给客户端。下面就请求管道中的对象进行详细叙述。(若有不妥之处,请海涵)。
HttpMessageHandler此类是所有管道处理中所有对象的基类,也就是说是最重要的一个类,下面我们借助.NET Reflector打开来看看该类的定义
该类是一个抽象类并且其中最重要的两个方法是 Dispose 和 SendAsyc ,对于Dispose方法的实现,我们查看如下:
public void Dispose() { this.Dispose(1); GC.SuppressFinalize(this); return; } protected virtual void Dispose(bool disposing) { }
就是个非常标准的实现资源回收的方法,但是其并未实现某个资源的回收,下面会用到,先搁置在这里。
对于第二个方法是SendAsync,看到此方法的第一个参数为HttpRequestMessage,我们能想到此方法是用来处理传递进来的请求并返回Task<HttpResponMessage>对象来响应信息,至于第二个参数是与线程有关,通知取消某个操作请参看【CancellationToken】。
DelegatingHandler经过如上描述,对于请求和响应都是通过HttpMessageHandler来实现,这就相当于是首尾相连,但是真正实现其相连的角色而是DelegateHandler,并且该类并非仅仅是继承,而且还进行了相应的一些扩展,下面我们来看看该类的定义:
上述重要的两个方法 Dispose 和 SendAsync 以及 InnerHandler 字段,下面我们一一来看这三者。
第一个是Dispose,上述已经讲过在HttpMessageHandler中并未实现对资源的回收,从这里我们可以看出它对其进行了重写,说明可能是在其继承类DelegatingHandler中进行了资源回收,只是猜测,我们查看其具体实现就明了了。如下:
protected override void Dispose(bool disposing) { if (disposing == null) { goto Label_0029; } if (this.disposed != null) { goto Label_0029; } this.disposed = 1; if (this.innerHandler == null) { goto Label_0029; } this.innerHandler.Dispose(); Label_0029: base.Dispose(disposing); return; }
很显然,通过 this.Handler.Dispose(); 我们知道是实现了资源回收了的,那这个 InnerHandler 字段到底是干嘛的了,看其返回类型为HttpMessageHandler,说明是获得了HttpMessageHandler对象的引用,接着就是重写基类中的SendAsync方法,而调用此方法正是通过属性InnerHandler来调用。我们说过InnerHandler是获得对象HttpMessageHandler的引用说的更加明确就是下一个HttpMessageHandler处理程序的引用。
对于InnerHandler的实现连接下一个HttpMessageHandler似的委托链,类似如下:
温馨提示: 本文由Jm博客推荐,转载请保留链接: https://www.jmwww.net/file/67054.html
- 上一篇:windows 无法上网问题解决一例
- 下一篇:将xml的数据写入swing树形结构