Asynchronous Data Access to data source controls in ASP. NET2.0 (1)

The WeatherDataSource control is created in the front 2 text. The control runs based on the xml api provided by weather.com, and uses WebRequest and WebResponse to access data through HTTP. So far, the service has been accessed synchronously. Therefore, page processing is blocked until the Web request is complete. This method is effective for testing pages, and may also be effective on small sites, but it will be disastrous for websites receiving large volumes of communication traffic. For example, portal pages, the weather module may be very common.

Introduction
There are a large number of fixed threads in the thread pool that can be used for service requests. Unfortunately, this solution not only increases the limit but also increases the resource occupation by threads and CPU usage ). Therefore, when a page is blocked and waiting for another server, it is still occupying threads, which may lead to other incoming requests waiting for a longer time in the queue. This will lead to slow access to the site and reduce the CPU usage. In Visual Studio 2005, we introduced asynchronous pages so that controls can define the tasks they want to complete asynchronously, that is, they do not need to block the threads used to process requests. This section does not describe the details of asynchronous pages, such as Dmitry and Fritz Onion. This section describes how to use this function in the data source control and use the add-on framework to implement asynchronous data sources.
Background
In part 2, I indirectly mentioned some odd designs of the performanceview class:

Public abstract class performanceview { Public virtual void Select (DataSourceSelectArguments arguments, DataSourceViewSelectCallback callback ); Protected abstract IEnumerable ExecuteSelect ( DataSourceSelectArguments arguments ); ... }

You will notice that the public Select method does not actually return any data. Instead, it accepts a callback and uses this callback to return data. It only calls the protected ExecuteSelect and always executes synchronous data access) to retrieve the data to be returned to the data-bound control. The default implementation of the performanceview class does not actually perform any operations asynchronously. The reason is that there is no ready-made asynchronous data source control. However, the design of OM does allow asynchronous data access. In this design, data is available only after the asynchronous work is complete. Therefore, we have a callback-based model.
Those familiar with asynchronous APIs in the framework will notice the lack of asynchronous modes: Public Select, BeginSelect, and EndSelect methods. In these methods, the data binding control selects the methods to call. However, the data binding control cannot determine whether to choose synchronous API or asynchronous API. In addition, adding a property to a data binding control does not work. The data source control encapsulates detailed information about how to access data storage. Whether access to data storage occurs synchronously or asynchronously depends on whether the data source is based on semantics or custom attributes. The correct location of the potential "bool protected masyncdataaccess" attribute is suitable for the data source control. This also allows the data source control to perform data access, even if multiple data binding controls are bound to the same data source. So far, I have explained these subtle concepts contained in this architecture for many times. I hope I can clarify this design.
The last thing to note about asynchronous tasks is: whether or not the Page should execute any asynchronous tasks is entirely decided by the Page developers through the Async attribute of the Page command ). Therefore, any well-written data source control must degrade to implement synchronous data access as needed.
Framework

The rest of the example is used to demonstrate this point at the end of this series in this framework). The AsyncDataSource and asyncperformanceview base classes have been put together, these basic classes can be used to implement data source controls that can perform asynchronous data access. The following describes the framework content and some comments that help clarify its meaning:

Public abstract class AsyncDataSourceControl: performancecontrol, IAsyncDataSource { Private bool _ policmasyncdataaccess; Protected AsyncDataSourceControl (){ _ Required masyncdataaccess = true; } Public virtual bool extends masyncdataaccess { Get; set; } Bool IAsyncDataSource. IsAsync { Get {return _ Your masyncdataaccess & Page. IsAsync ;} } } Public abstract class asyncperformanceview: performanceview { Protected abstract IAsyncResult BeginExecuteSelect ( DataSourceSelectArguments arguments, AsyncCallback asyncCallback, Object asyncState ); Protected abstract IEnumerable EndExecuteSelect ( IAsyncResult asyncResult ); Protected override IEnumerable ExecuteSelect ( DataSourceSelectArguments arguments ){ // Implement // Abstract ExecuteSelect method, // Use BeginExecuteSelect and EndExecuteSelect, // Enable blocking // Synchronize data access. } Private IAsyncResult OnBeginSelect (object sender, EventArgs e, AsyncCallback asyncCallback, Object extraData ); Private void OnEndSelect (IAsyncResult asyncResult ); Public override void Select (DataSourceSelectArguments arguments, DataSourceViewSelectCallback callback ){ If (_ owner. IsAsync ){ // Use OnBeginSelect and OnEndSelect // As the BeginEventHandler and EndEventHandler methods, // Call Page. RegisterAsyncTask, // Specify the requirements // Perform asynchronous work. These methods will // Call a specific // Data source implementation by calling // // Abstract BeginExecuteSelect and EndExecuteSelect // Method. } Else { // Execute synchronous data access Base. Select (arguments, callback ); } } ... }