《ASP.NET Web API标准的“管道式”设计_》由会员分享，可在线阅读，更多相关《ASP.NET Web API标准的“管道式”设计_（14页珍藏版）》请在金锄头文库上搜索。
1、ASP.NET Web API标准的“管道式”设计_ ASP.NET Web API的核心框架是一个消息处理管道，这个管道是一组HttpMessageHandler的有序组合。这是一个双工管道，恳求消息从一端流入并依次经过全部HttpMessageHandler的处理。在另一端，目标HttpController被激活，Action方法被执行，响应消息随之被生成。响应消息逆向流入此管道，同样会经过逐个HttpMessageHandler的处理。这是一个独立于寄宿环境的抽象管道，如何实现对恳求的监听与接收，以及将接收的恳求传入消息处理管道进行处理并将管道生成的响应通过网络回传给客户端，这就是Web
2、 API寄宿需要解决的问题。 名目 一、HttpMessageHandler 二、DelegatingHandler 三、HttpServer 四、HttpRoutingDispatcher 五、HttpControllerDispatcher 一、HttpMessageHandler ASP.NET Web API的消息处理管道由一组HttpMessageHandler经过“首尾相连”而成，ASP.NET Web API之所以具有较高的可扩展性，主要源于采纳的管道式设计。虽然ASP.NET Web API框架旨在实现针对恳求的处理和响应的回复，但是采纳的处理策略因具体的场景而不同。 我们不行
3、能也没有必要创建一个“万能”的处理器来满足全部的恳求处理需求，倒不如让某个处理器只负责某个单一的消息处理功能。在具体的应用场景中，我们可以依据具体的消息处理需求来选择所需的处理器并组成一个完整的消息处理管道。在这里这个用于完成某个单一消息处理功能的处理器就是HttpMessageHandler。 这里的“消息处理”具有两个层面的含义，既包括针对恳求消息的处理，还包括针对响应消息的处理。HttpMessageHandler挺直或者间接继承自具有如下定义的抽象类型HttpMessageHandler，该类型定义在命名空间“System.Net.Http”下。ASP.NET Web API通过类型H
4、ttpRequestMessage和HttpResponseMessage来表示管道处理的恳求消息和响应消息，所以对HttpMessageHandler的定义就很好理解了。 1: public abstract class HttpMessageHandler : IDisposable 2: 3: public void Dispose(); 4: protected virtual void Dispose(bool disposing); 5: protected abstract Task SendAsync(HttpRequestMessage request, Cancellati
5、onToken cancellationToken); 6: 如上面的代码片断所示，抽象类HttpMessageHandler定义了一个受爱护的抽象方法SendAsync，这是一个采纳针对Task的“并行编程模式”的异步方法，在后续的章节中我们会看到ASP.NET Web API的应用程序接口基本上都采纳这样的定义方式。对于这个SendAsync方法来说，request参数表示传递给当前HttpMessageHandler进行处理的恳求，这是一个HttpRequestMessage对象。另一个参数cancellationToken是一个用于发送取消操作信号的CancellationToken对
6、象，假如读者对.NET中的并行编程具有基本了解的话，信任对这个类型不会感到生疏。 针对恳求消息和响应消息的处理均体现在这个SendAsync方法上。具体来说，针对恳求消息的处理挺直实现在SendAsync方法中，而针对响应消息的处理则通过其返回的Task对象来完成。由HttpMessageHandler组成的消息处理管道以及恳求消息和响应消息在管道中的“流淌”基本上可以通过右图来体现。 抽象类HttpMessageHandler实现了IDisposable接口，它根据“标准”的方式实现Dispose方法。如下面的代码片断所示，当我们调用Dispose方法的时候，HttpMessageHandl
7、er并没有执行任何资源回收操作。当我们通过继承这个抽象类自定义HttpMessagHandler的时候，可以将资源回收操作实现在重写的Dispose方法中。 1: public abstract class HttpMessageHandler : IDisposable 2: 3: /其他操作 4: public void Dispose() 5: 6: this.Dispose(true); 7: GC.SuppressFinalize(this); 8: 9: 10: protected virtual void Dispose(bool disposing) 11: 12: 二、Del
8、egatingHandler 我们说ASP.NET Web API消息处理管道是通过一组有序的HttpMessagHandler“首尾相连”而成，具体实现“管道串联”是通过DelegatingHandler这个类型来完成的。顾名思义，DelegatingHandler具有托付功能，当它自己负责的消息处理任务完成之后可以托付另一个HttpMessagHandler进行后续的处理。假如这个被托付的也是一个DelegatingHandler对象，不就可以组成一个托付链了吗?而这个托付链不就是由一个个DelegatingHandler组成的消息处理管道吗? 如下面的代码片断所示，DelegatingH
9、andler是一个继承自HttpMessageHandler类的抽象类。上面我们所说的这个被托付的HttpMessagHandler由它的属性InnerHandler表示。DelegatingHandler重写了定义在其类的抽象方法SendAsync来调用InnerHandler属性的同名方法。 1: public abstract class DelegatingHandler : HttpMessageHandler 2: 3: protected internal override Task SendAsync(HttpRequestMessage request, Cancellati
10、onToken cancellationToken); 4: public HttpMessageHandler InnerHandler get; set; 5: 正如上面所说，假如ASP.NET Web API的消息处理管道均由DelegatingHandler组成(位于管道尾端的HttpMessageHandler除外)，我们就可以依据其InnerHandler获得对被托付的HttpMessageHandler对象的引用，由此便构成具有如上图所示的链式结构。组成ASP.NET Web API核心框架的消息处理管道就这么简洁。 三、HttpServer 一般来说，对于构成ASP.NET W
11、eb API消息处理管道的全部HttpMessageHandler来说，除了处于尾端的那一个之外，其余的均为DelegatingHandler，那么通过InnerHandler属性维持着“下一个” HttpMessageHandler。作为这个HttpMessageHandler链“龙头”的是一个HttpServer对象，该类型定义在命名空间“System.Web.Http”下。 如下面的代码片断所示，HttpServer挺直继承自DelegatingHandler。它具有两个重要的只读属性(Configuration和Dispatcher)，我们可以通过前者得到用于配置整个消息处理管道的Ht
12、tpConfiguration对象，另外一个属性Dispatcher返回的是处于整个消息处理管道“尾端”的HttpMessageHandler。 1: public class HttpServer : DelegatingHandler 2: 3: public HttpConfiguration Configuration get; 4: public HttpMessageHandler Dispatcher get; 5: 6: public HttpServer(); 7: public HttpServer(HttpMessageHandler dispatcher); 8: pu
13、blic HttpServer(HttpConfiguration configuration); 9: public HttpServer(HttpConfiguration configuration, HttpMessageHandler dispatcher); 10: 11: protected override void Dispose(bool disposing); 12: protected virtual void Initialize(); 13: protected override Task SendAsync(HttpRequestMessage request,
14、CancellationToken cancellationToken); 14: HttpServer的Configuration和Dispatcher属性均可以在相应的构造函数中初始化。假如在构造HttpServer的时候没有显式指定这两个属性的值(调用默认的无参构造函数创建HttpServer)，在默认状况下会创建一个HttpConfiguration作为Configuration的属性值，而作为Dispatcher属性值的则是一个HttpRoutingDispatcher对象，该类型定义在命名空间“System.Web.Http.Dispatcher”下。除此之外。由于HttpConf
15、iguration类型实现了IDisposable接口，所以HttpServer重写了虚方法Dispose并在该方法中完成了对HttpConfiguration对象的释放。 当HttpServer对象被胜利创建之后，对应的消息处理管道的“一头一尾”已经确定下来。一头指的就是HttpServer对象本身，一尾指的自然就是通过Dispatcher属性引用的HttpMessageHandler对象了。ASP.NET Web API框架最大的扩展性就在于我们可以依据具体的消息处理需求来“定制”这个消息处理管道，它允许我们将自定义的HttpMessageHandler根据如左图所示的方式“安装”到这一头一尾之间，但是这些处于“中间位置”的HttpMessageHandler是如何注册呢? 既然整个管道都是由HttpConfiguration进行配置，那么自定义HttpMessageHandler的注册自然也可以利用它来完成。如下面的代码片断所示，HttpConfiguration具有一个只读的集合类型的MessageHandlers，需要注册的HttpMessageHandler需要添加到此集合之中。由于这是一个元素类型为Delegatin
