Although it could be seen that
async/await replaces the use that is given to
BackgroundWorker , I do not think that is the case. moreover, from my point of view, they are not only different things but also have different purposes.
It is possible that in specific cases, you can use
BackgroundWorker indistinctly, but that does not necessarily convert them into equivalents.
The purpose of
BackgroundWorker is to define a task that will run in the background in another thread. Basically, the problem that the
BackgroundWorker tries to solve is to execute a single heavy task in the background to avoid that the interface remains in a non-responsive state .
A classic example would be for example a data synchronization. A client has some local data that periodically performs a complete synchronization to the server part. That use case fits with the approach and operation of
async / await
The goal of using
async/await is different. It is intended to execute a deferred logic, without stopping the execution of the program (or on the contrary for the case of
await ). It is not necessarily a heavy task to be relegated to the background, but simply a request / method that we invoke asynchronously so as not to stop the execution of the process.
A typical case of using
async/await could be seen when sending a client form to a server or when logging in with an external provider (such as LDAP for example), depending on your needs, you might not want to stop execution (using
async ) and in others where you need to wait for the answer before continuing (using the
It is important to note that
async/await does not use other threads of execution.
It can be very helpful to review the article in the MSDN - Asynchronous Programming with Async and Await .
In that link, there is a relevant paragraph about which operations are discouraged for the background worker:
The async-based approach to asynchronous programming is preferable to
existing approaches in almost every case. In particular, this approach
is better than BackgroundWorker for IO-bound operations because the
code is simpler and you do not have to guard against race conditions.
In combination with Task.Run, async programming is better than
BackgroundWorker for CPU-bound operations because async programming
separates the coordination details of running your code from the work
that Task.Run transfers to the threadpool.
This approach based on
async for asynchronous programming is
preferable to existing approaches in almost any case. In
In particular, this approach is better than
operations associated with
E/S because the code is simpler and not
You need to protect yourself against thread desynchronization. In combination
[Task.Run] , asynchronous programming is better than
BackgroundWorker for operations linked to the CPU because it separates
the details of coordination between the implementation of the code and the work
who performs the task when transferring from
I have left the original version because I have taken certain liberties with the translation.
Despite everything, I still believe that
BackgroundWorker still has its use case, the difference is that nowadays the use cases in which
BackgroundWorker fit better are less, since every time we focus on atomize as much as possible the operations in microllamadas and we do not have heavy operations (as a general rule) to run in the background.
Except for those specific cases, I believe that the current recommendation that in the first section of this article is more than correct for the programming paradigm that is usually used in these times.
The model is quite simple in most cases: For the
code linked to
E/S , you perform an operation
await that returns
Task<T> of an asynchronous method.
For the code associated with CPU, you perform a
start in a thread in the background with the
await directive is where the magic happens, because it delegates the
control to the invoker of the method that executes
await . This is what
ultimately allow the UI to be responsive, or to a service