正如前一篇文章所说的那样， WebRequestExecutor是客户端网络访问的基础结构的唯一扩展点，而XMLHttpExecutor是其默认实现。在ASP.NET AJAX中，开发人员能够将自定义的WebRequestExecutor子类设为默认的Executor，也可以为某一个WebRequest指定一个 特定的Executor。虽然一般来说XMLHttpExecutor已经足够大多数应用，但是既然ASP.NET AJAX提供了这个功能，我们也根据默认的类进行一下这方面的学习。
WebRequestExecutor
在ASP.NET AJAX客户端脚本中，Sys.Net.WebRequestExecutor是一个抽象类，它有以下成员：
WebRequestExecutor很简单，接下来我们从ASP.NET AJAX中的默认实现来自己看一下具体的实现方式。
XMLHttpExecutor
大部分的属性与方法的意义实在不大。我们就来看几个关键方法的实现吧，它们会涉及到WebRequestExecutor的状态，即使我们的实现不同，这些状态一般来说还是保持统一的。
1、构造函数
构造函数的作用其实只是初始化所有的状态，它们分别是：
2、executeRequest方法
调用这个方法就会构造一个XMLHttpRequest对象，并发起一个请求。代码如下：
Sys.Net.XMLHttpRequest.executeRequest方法
可以发现，在这个方法被调用之后，started属性被设为了true，以此避免同一个Executor被执行两次。
3、_onReadyStateChange方法
这个方法是XMLHttpRequest对象的onreadystatechange回调函数。代码如下：
_onReadyStateChange方法
在这个方法里，只会判断XMLHttpRequest对象的readyState的值，等于4则表示收到了回复，已经执行完毕了，然后进入其 他逻辑。这个和“标准”的AJAX逻辑似乎有些不同，这是因为在ASP.NET AJAX中的WebRequestExecutor中，会将判断response结果的逻辑交由其它代码完成。在Executor中只需表示 “Complete”即可，其余的，都交给别人去吧。
在这个方法中，responseAvailable被设为了true，表示已经得到了Response——其实在ASP.NET AJAX这部分模型中，这个Response对象就是当前的WebRequestExectuor自身。
4、_onTimeout方法
timeout触发器会调用这个方法。代码如下：
_timeout方法
当一个请求超时的时候，需要调用XMLHttpRequest.abort方法来取消这个请求。同时，timeout属性被设为了true。
5、abort方法
这个方法负责取消一个请求。代码如下：
abort方法
这个方法会调用XMLHttpRequest对象的abort方法来取消这个请求，并且将aborted属性设为true。
上面就是XMLHttpExecutor类的“分析”了，其实代码都非常简单（有时候我会想，难道我是为了系列文章内容的完整性才写这些吗？它们的质量 有没有到一定的标准？它们有一定的存在价值吗？）。我们来思考一个问题，到底什么时候我们需要自定义一个Executor？我们需要满足一个什么样的功 能？在实际应用中XMLHttpRequest的功能还不够吗？写一个IFrameExecutor？个人认为，一般来说，如果真的要对 WebRequestExecutor进行扩展的话，估计也是在XMLHttpExecutor的基础上进行扩展了，我们可以依靠对于 XMLHttpExecutor的继承或者封装附加一些新的功能，例如统一的身份验证和异常处理等等。在与这篇“分析”相对应的“示例”中，我将提供一个 继承于XMLHttpExecutor的类，它能够将页面上所有请求的全部或部分信息输出在页面上，方便开发人员跟踪与调试。当然，这只是一个在开发过程 中的应用。至于完整定义一个WebRequestExecutor……那么为客户端的单元测试定义一个WebRequestExecutor的mock对 象吧。
WebRequestExecutor
在ASP.NET AJAX客户端脚本中，Sys.Net.WebRequestExecutor是一个抽象类，它有以下成员：
- webRequest只读属性：这个属性已经在Sys.Net.WebRequestExecutor得到定义，一般不用去关心它。
- started只读属性：抽象属性，表明该Executor是否已经开始执行了（或执行过了）。
- responseAvailable只读属性：抽象属性，表明该Executor是否已经得到response了。
- timeOut只读属性：抽象属性，表明该Executor是否已经超时。
- aborted只读属性：抽象属性，表明该Executor是否已经被取消。
- responseData只读属性：抽象属性，返回字符串形式的response内容。
- statusCode只读属性：抽象属性，返回请求结果的状态代码。
- statusText只读属性：抽象属性，返回字符串形式表示的请求结果状态。
- xml只读属性：抽象属性，返回xml形式的response内容。
- object只读属性：这个属性已经在Sys.Net.WebRequestExecutor得到定义，用于返回一个表请求明结果的对象。
- executeRequest方法：抽象方法，用于执行当前的请求。
- abort方法：抽象方法，用于取消当前的请求。
- getResponseHeader方法：抽象方法，通过指定的name，从请求结果的Header中获得对应的值。
- getAllResponseHeaders方法：抽象方法，返回字符串形式表示的所有的Header信息。
WebRequestExecutor很简单，接下来我们从ASP.NET AJAX中的默认实现来自己看一下具体的实现方式。
XMLHttpExecutor
大部分的属性与方法的意义实在不大。我们就来看几个关键方法的实现吧，它们会涉及到WebRequestExecutor的状态，即使我们的实现不同，这些状态一般来说还是保持统一的。
1、构造函数
构造函数的作用其实只是初始化所有的状态，它们分别是：
- responseAvailable属性设为false
- timedOut属性设为false
- aborted属性设为false
- started属性设为false
2、executeRequest方法
调用这个方法就会构造一个XMLHttpRequest对象，并发起一个请求。代码如下：
Sys.Net.XMLHttpRequest.executeRequest方法
可以发现，在这个方法被调用之后，started属性被设为了true，以此避免同一个Executor被执行两次。
3、_onReadyStateChange方法
这个方法是XMLHttpRequest对象的onreadystatechange回调函数。代码如下：
_onReadyStateChange方法
在这个方法里，只会判断XMLHttpRequest对象的readyState的值，等于4则表示收到了回复，已经执行完毕了，然后进入其 他逻辑。这个和“标准”的AJAX逻辑似乎有些不同，这是因为在ASP.NET AJAX中的WebRequestExecutor中，会将判断response结果的逻辑交由其它代码完成。在Executor中只需表示 “Complete”即可，其余的，都交给别人去吧。
在这个方法中，responseAvailable被设为了true，表示已经得到了Response——其实在ASP.NET AJAX这部分模型中，这个Response对象就是当前的WebRequestExectuor自身。
4、_onTimeout方法
timeout触发器会调用这个方法。代码如下：
_timeout方法
当一个请求超时的时候，需要调用XMLHttpRequest.abort方法来取消这个请求。同时，timeout属性被设为了true。
5、abort方法
这个方法负责取消一个请求。代码如下：
abort方法
这个方法会调用XMLHttpRequest对象的abort方法来取消这个请求，并且将aborted属性设为true。
上面就是XMLHttpExecutor类的“分析”了，其实代码都非常简单（有时候我会想，难道我是为了系列文章内容的完整性才写这些吗？它们的质量 有没有到一定的标准？它们有一定的存在价值吗？）。我们来思考一个问题，到底什么时候我们需要自定义一个Executor？我们需要满足一个什么样的功 能？在实际应用中XMLHttpRequest的功能还不够吗？写一个IFrameExecutor？个人认为，一般来说，如果真的要对 WebRequestExecutor进行扩展的话，估计也是在XMLHttpExecutor的基础上进行扩展了，我们可以依靠对于 XMLHttpExecutor的继承或者封装附加一些新的功能，例如统一的身份验证和异常处理等等。在与这篇“分析”相对应的“示例”中，我将提供一个 继承于XMLHttpExecutor的类，它能够将页面上所有请求的全部或部分信息输出在页面上，方便开发人员跟踪与调试。当然，这只是一个在开发过程 中的应用。至于完整定义一个WebRequestExecutor……那么为客户端的单元测试定义一个WebRequestExecutor的mock对 象吧。
感觉“深入Atlas系列”的文章有些难写了，有时候我也会忽然不知道应该写什么。希望大家对我的文章多提一些意见和建议。谢谢大家！
本文转自 jeffz 51CTO博客，原文链接：http://blog.51cto.com/jeffz/60689，如需转载请自行联系原作者
