Build Better UIs with the Asynchronous Support in .NET 2.0

synchronous programming has always been a difficult and time-consuming process in Windows programming. Until now, developers typically wrote asynchronous code in .NET by using an asynchronous pattern with a Begin/End method that returned an IAsyncResult object, using either delegates or an explicit threading technique as the model. However, it's far better to have an infrastructure-based approach with intrinsic support for asynchronous processing within .NET controls and libraries. The .NET framework version 2.0 takes this approach by providing a standard asynchronous pattern with a base infrastructure that helps you either use the intrinsic framework-supplied BackgroundWorker component in your classes or for building your components manually with asynchronous support. In addition, Whidbey natively supports asynchronous processing for many controls and for T-SQL statements. In this article, you'll see how to use the model to fetch data asynchronously using a SqlCommand object, and how to build a class that uses the BackGroundWorker component.

Author Note: The sample code that accompanies this article uses VS.NET Beta for the samples. The DataBindingEx.sln requires the "Yukon" version of SQL Server, but the other samples do not.

Although this article focuses on asynchronous programming in Whidbey it is important that you understand the asynchronous model itself. The sidebar "How the Asynchronous Model Works" provides several examples. If you're not thoroughly familiar with programming asynchronous operations, review the sidebar before reading the rest of this article.

Asynchronous Scenarios in .NET 2.0
The rest of this article contains a practical sample of programming asynchronous processes in .NET 2.0. The first scenario involves an asynchronous data fetch using the new Asynchronous support offered in the SqlCommand object. Later, I'll show you how to use the new BackGroundWorker component.