摘要：本文是介绍数据源控件的系列文章中的第三篇。在本文中，Nikhil 着重介绍如何执行并封装异步数据访问，同时演示可重用的异步数据访问框架，该框架根据 Microsoft Visual Studio 2005 中的可用功能来建立。

　　在第 1 部分和第 2 部分中，建立了 WeatherDataSource 控件，该控件针对 weather.com（英文）所提供的 XML API 来运行，使用 WebRequest 和 WebResponse 来通过 HTTP 访问数据。迄今为止，均是同步访问该服务。因此，页面处理被阻止，直到 Web 请求完成为止。此方法对于测试页面是有效的，在小站点上也可能有效，但是在接收大量通信流量的站点上则会惨败；例如门户页面，天气模块在其中可能非常常见。

　　引言

　　在线程池中有固定不变的大量线程可用于服务请求，遗憾的是，该解决方案并非仅仅提高限制（还会增加线程占用资源以及 CPU 占用资源）。因此，当一个页面被阻止而等候另一个服务器时，它还在占用线程，因而可能会导致其他传入的请求在队列中等候更长的时间。这将导致对站点的访问变慢，并降低 CPU 的利用率。在 Visual Studio 2005 中，我们引入了异步页面，这使得控件能够定义它们希望异步完成的任务，即，无需阻止用来处理请求的线程。在此将不介绍异步页面本身的详细信息，Dmitry（英文）和 Fritz Onion（英文）中以前已经有所介绍。此处要介绍的是如何在数据源控件中利用此功能，使用加载项框架来实现异步数据源。

　　背景

　　在第 1 部分中，间接提到了 DataSourceView 类的有些古怪的设计：

　　您会注意到，公共 Select 方法实际上并不返回任何数据。而是接受一个回拨，并通过该回拨来返回数据。它只调用受保护的 ExecuteSelect（它始终执行同步数据访问）来检索要退还给数据绑定控件的数据。DataSourceView 类的默认实现实际上不会异步执行任何操作。原因在于，并不存在任何现成的异步数据源控件。但 OM 的设计确实允许实现异步数据访问，在这种设计下，数据在异步工作完成之后才可用。因此，我们就有了一个基于回拨的模型。

　　那些熟悉框架中的异步 API 的人会注意到缺少了异步模式：公共 Select、BeginSelect 和 EndSelect 方法，在这些方法中，数据绑定控件选择要调用哪些方法。但是，数据绑定控件并不能确定是选择同步 API 还是选择异步 API。此外，在数据绑定控件上添加属性也毫无作用。数据源控件封装了有关如何访问数据存储的详细信息，对数据存储的访问是同步发生还是异步发生应该根据数据源是否基于语义来决定或者根据自定义属性来决定。潜在的“bool PerformAsyncDataAccess”属性的正确位置适合于数据源控件本身。这还使得数据源控件可以使用一种方法来执行数据访问，即使多个数据绑定控件被绑定到同一个数据源。至此已多次解释了该体系结构所蕴涵的这些微妙的概念，但愿能阐明该设计。

　　关于异步任务，最后要注意的一点是：页面是否应该执行任何异步工作完全由页面开发人员最终决定（通过 Page 指令的 Async 属性）。因此，任何编写良好的数据源控件必须退化为根据需要来执行同步数据访问。

　　框架

　　在此框架中（在此系列结尾会用示例的剩余部分来演示这一点），已将 AsyncDataSource 和 AsyncDataSourceView 基类放在一起，这些基类可以用于实现能够执行异步数据访问的数据源控件。以下大概介绍了框架内容，以及有助于弄清楚其含义的一些注释：