I found Difference between […]Async and Begin[…] .net asynchronous APIs question but this answer confused me a little bit.
Talking about these patterns, Stephen said:
Most *Async methods (with corresponding *Completed events) are using the Event-Based Asynchronous Pattern. The older (but still perfectly valid) Begin* and End* is a pattern called the Asynchronous Programming Model.
The Socket class is an exception to this rule; its *Async methods do not have any corresponding events; it’s essentially just APM done in a way to avoid excessive memory allocations.
I get it as using *Async methods are more efficient, at least when it comes to sockets.
But then he mentioned Task Parallel Library:
However, both APM and EBAP are being replaced with a much more flexible approach based on the Task Parallel Library. Since the TPL can wrap APMs easily, older classes will likely not be updated directly; extension methods are used to provide Task equivalents for the old APM methods.
I found TPL and Traditional .NET Asynchronous Programming on MSDN, I know the basics of TPL, creating tasks, cancellations, continuations, etc but I still fail to understand these:
What are the advantages of Asynchronous Programming Model (APM) and Event-based Asynchronous Pattern (EAP) compared to each other? How does TPL can wrap APMs easily mean that both APM and EAP are being replaced with TPL?
And most importantly: Which should I use in socket programming;
- APM?
- EAP?
- APM or EAP wrapped by a Task?
- TPL by using the blocking methods of Socket class in tasks?
- Other?
It doesn’t. Wether APM and EAP will be replaced by TAP (Task Asynchronous Pattern) or not in new APIs has nothing to do with this. I would expect TAP to replace APM and EAP for a variety of reasons. The main reason to me is that the code you write for using the TAP composes much better. Doing
.ContinueWith(/* ... */).ContinueWith(/* ... */)generally reads much better than the corresponding code you would need to write to chain async calls through Begin/End methods, even if you don’t take into account the options you can pass to ContinueWith to determine if the continuation should run. The TPL also provides various combinators for Tasks, such asWaitAllandWaitAny, that can make some scenarios much easier. The language support coming in C# and VB.NET via the async/await keywords will make this even easier.Being able to wrap APMs in the TAP makes it easier to switch to this pattern because it means you don’t have to rewrite existing code to make it fit in the new model.
I would recommend using the TAP wrapping the APM methods on Socket. Unless you can prove that the extra overhead of wrapping the Begin/End methods into a Task are the difference between scalable/fast enough or not, I would take advantage the ease of coding of the TAP.