When a method call is made on an object, the client is typically blocked while the object executes the call, and control returns to the client only when the method completes execution and returns. However, there are quite a few cases in which you want to call methods asynchronously; that is, you want control to return immediately to the client, while the object executes the called method in the background and then somehow lets the client know that the method has completed execution. Such an execution mode is called asynchronous method invocation , and the action is known as an asynchronous call. Asynchronous calls allow you to improve availability, increase throughput and performance, and scale up your application.

In the past, developers often had to handcraft proprietary mechanisms for asynchronously invoking calls on their components. One recurring mechanism was to have the object spin off a worker thread to process the client’s request and immediately return control to the client. The object would later signal the client somehow when the call completed (if the client wanted to know), and the client had to have some way of distinguishing between multiple method completions. These mechanisms were difficult to develop and test, and they forced developers to spend a disproportionate amount of their time reinventing the wheel instead of adding business value to their applications. In addition, such solutions coupled the clients to the objects and were not consistently designed or implemented. Different vendors provided slightly different solutions, requiring at times different programming models on the client side. This predicament diminished the benefits of component-oriented programming, because the component developers had to make some assumptions about the client’s way of using the component, and vice versa.

The .NET mechanism for asynchronous calls is a mainstream facility used consistently and pervasively across the .NET application frameworks and base classes. .NET asynchronous calls are an essential addition to your arsenal as a component developer, because implementing robust asynchronous execution on your own is a demanding task, requiring a lot of effort spent on design, implementation, and testing. By providing support for asynchronous calls, .NET lets you focus on the domain problems at hand, rather than on complicated asynchronous plumbing. First, I’ll explain the requirements for any asynchronous system in general. Then, because .NET asynchronous calls are based on delegates (introduced in Chapter 6), this chapter takes a closer look at delegates and then proceeds to describe how best to use .NET asynchronous calls.