Asynchronous Operations (WCF Data Services)
Important
WCF Data Services has been deprecated and will no longer be available for download from the Microsoft Download Center. WCF Data Services supported earlier versions of the Microsoft OData (V1-V3) protocol only and has not been under active development. OData V1-V3 has been superseded by OData V4, which is an industry standard published by OASIS and ratified by ISO. OData V4 is supported through the OData V4 compliant core libraries available at Microsoft.OData.Core. Support documentation is available at OData.Net, and the OData V4 service libraries are available at Microsoft.AspNetCore.OData.
RESTier is the successor to WCF Data Services. RESTier helps you bootstrap a standardized, queryable, HTTP-based REST interface in minutes. Like WCF Data Services before it, Restier provides simple and straightforward ways to shape queries and intercept submissions before and after they hit the database. And like Web API + OData, you still have the flexibility to add your own custom queries and actions with techniques you're already familiar with.
Web applications must accommodate higher latency between client and server than applications that run inside internal networks. To optimize the performance and user experience of your application, we recommend using the asynchronous methods of the DataServiceContext and DataServiceQuery<TElement> classes when accessing WCF Data Services servers over the Web.
Although the WCF Data Services servers process HTTP requests asynchronously, some methods of the WCF Data Services client libraries are synchronous and wait until the entire request-response exchange is completed before continuing execution. The asynchronous methods of the WCF Data Services client libraries do not wait for this exchange to complete and can allow your application to maintain a responsive user interface in the meantime.
You can perform asynchronous operations by using a pair of methods on the DataServiceContext and DataServiceQuery<TElement> classes that start with Begin and End respectively. The Begin methods register a delegate that the service calls when the operation is complete. The End methods should be called in the delegate that is registered to handle the callback from the completed operations. When you call the End method to complete an asynchronous operation, you must do so from the same DataServiceQuery<TElement> or DataServiceContext instance that you used to begin the operation. Each Begin method takes a state
parameter that can pass a state object to the callback. This state object is retrieved from the IAsyncResult that is supplied with the callback and is used to call the corresponding End method to complete the asynchronous operation. For example, when you supply the DataServiceQuery<TElement> instance as the state
parameter when you call the BeginExecute method on the instance, the same DataServiceQuery<TElement> instance is returned by the IAsyncResult. This instance of DataServiceQuery<TElement> is then used to call the EndExecute method to complete the query operation. For more information, see How to: Execute Asynchronous Data Service Queries.
Note
Only asynchronous operations are supported by the client libraries that are provided in the .NET Framework for Silverlight. For more information, see WCF Data Services (Silverlight).
The .NET Framework client libraries support the following asynchronous operations:
Operation | Methods |
---|---|
Executing a DataServiceQuery<TElement>. | - BeginExecute - EndExecute |
Executing a query from the DataServiceContext. | - BeginExecute - EndExecute |
Executing a batch query from the DataServiceContext. | - BeginExecuteBatch - EndExecuteBatch |
Loading a related entity into the DataServiceContext. | - BeginLoadProperty - EndLoadProperty |
Saving changes to objects in the DataServiceContext | - BeginSaveChanges - EndSaveChanges |
Threading Considerations for Asynchronous Operations
In a multi-threaded application, the delegate that is registered as a callback for the asynchronous operation is not necessarily invoked on the same thread that was used to call the Begin method, which creates the initial request. In an application where the callback must be invoked on a specific thread, you must explicitly marshal the execution of the End method, which handles the response, to the desired thread. For example, in Windows Presentation Foundation (WPF)-based applications and Silverlight-based applications, the response must be marshaled back to the UI thread by using the BeginInvoke method on the Dispatcher object. For more information, see Querying the Data Service (WCF Data Services/Silverlight).