Criteria for Exposing the IAsyncResult Pattern in Addition to the Event-based Pattern
While the Event-based Asynchronous Pattern has many benefits under the previously mentioned scenarios, it does have some drawbacks, which you should be aware of if performance is your most important requirement.
There are three scenarios that the event-based pattern does not address as well as the IAsyncResult pattern:
You can address these scenarios by using the event-based pattern, but doing so is more cumbersome than using the IAsyncResult pattern.
Developers often use the IAsyncResult pattern for services that typically have very high performance requirements. For example, the polling for completion scenario is a high-performance server technique.
Additionally, the event-based pattern is less efficient than the IAsyncResult pattern because it creates more objects, especially EventArgs, and because it synchronizes across threads.
The following list shows some recommendations to follow if you decide to use the IAsyncResult pattern:
Only expose the IAsyncResult pattern when you specifically require support for WaitHandle or IAsyncResult objects.
Only expose the IAsyncResult pattern when you have an existing API that uses the IAsyncResult pattern.
If you have an existing API based on the IAsyncResult pattern, consider also exposing the event-based pattern in your next release.
Only expose IAsyncResult pattern if you have high performance requirements which you have verified cannot be met by the event-based pattern but can be met by the IAsyncResult pattern.