Create a simple asynchronous calling pattern for Windows application

Brief introduction

I recently wrote a number of smart client applications, summarizing the asynchronous invocation methods that enable applications to call Web service in the background without freezing the foreground interface. Although the current. NET framework itself has provided a mechanism for asynchronous invocations, I find this mechanism more difficult to grasp in Windows applications because you need the right control over the user interface threading process.

In this article, I'll teach you a simple way to implement an asynchronous call to a Web service in a Windows application, in which you no longer have to consider the interaction of the background thread with the foreground interface thread.

Service agent

Visual studio®. NET generates a better Web service proxy class through which Web services can be used asynchronously, but this proxy class implements the asynchronous invocation mechanism of the. NET framework itself, which, as mentioned above, is not very convenient for Windows applications. For this reason, I generally do not use the generated proxy class directly, but instead increase the service proxy class in the middle.

A service proxy class is a class that adds additional functionality that can help client programs interact with Web services. The service proxy class implements many useful functions, including data caching, secure identity management, off-line operation support, and so on. The Service Broker created in this article parallels the common proxy class of the. NET framework itself to implement a simpler asynchronous invocation pattern.

User interface Threads

The application starts with a thread that creates and manages the user interface, which is called a user interface thread. Most developers instinctively use a user interface thread to do all the work, including Web service invocation, remote object invocation, database access, and so on, most of the usage and performance problems are caused by this inappropriate method.

The essence of the problem is that you can never accurately predict the time it takes to access a Web service, a remote object, or a database. And when you make this kind of call in a user interface thread, the user interface is likely to have an annoying freeze.

Naturally, you would put this kind of call in a separate thread, but I went a step further and recommended that you make all the non-user interface workshops in a separate thread. My point of view is that the user interface thread is used only to manage the user interface, and all object calls that you cannot guarantee good response times should be asynchronous, both within the process, across the process, or across the computer.

In any case, to simplify the asynchronous invocation pattern that the user interface threading handles, I have implemented a simple asynchronous invocation pattern similar to one of the features in Visual Studio 2005. As a start, let's first explain how the asynchronous invocation pattern works in the current. NET framework.

. NET Asynchronous invocation pattern

Each Web function of a system-generated Web service proxy class has a begin and an end method, and each object that supports the. NET Framework asynchronous invocation pattern is similar to this one. When an asynchronous call begins, the client responds immediately when it calls the Begin method, or immediately after the independent thread that accesses the Web service is established. At some point after that, when the Web service access is complete, the client calls the end method again.

But how does the client know when to call the End method? The Begin method returns a IAsyncResult object that can help you keep track of the process of an asynchronous call or explicitly wait for the background thread to complete, but if you do this in a user interface thread, you can reduce the synchronization of the entire system. A better approach is to register a callback function in the user interface process and generate an automatic notification when other work is completed.

Let's look at a sample code in which we get some customer data from a Web service, which is done through the Getcustomerdata method in the Web service proxy class. We can start this Web service invocation and register a callback function with the following code to create the function of interacting with the application in the user interface thread.

private void SomeUIEvent( object sender, EventArgs e )
{
　 // Create a callback delegate so we will
　 // be notified when the call has completed.
　 AsyncCallback callBack = new
　　　AsyncCallback( CustomerDataCallback );
　 // Start retrieving the customer data.
　 _proxy.BeginGetCustomerData( "Joe Bloggs", callBack, null );
}