Replace "Async / Await" with "Backgroundworker"?

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 async or BackgroundWorker indistinctly, but that does not necessarily convert them into equivalents.

BackgroundWorker

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 BackgroundWorker .

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 await ).

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.

Home translation:

  

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 BackgroundWorker for   operations associated with E/S because the code is simpler and not   You need to protect yourself against thread desynchronization. In combination   with [Task.Run][2] , 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 threadpool

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   a Task or Task<T> of an asynchronous method.

     

For the code associated with CPU, you perform a await of%   start in a thread in the background with the Task.Run method.

     

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   be elastic.

In principle they are not exactly the same, although everything that is possible to do with BackgroundWorker can be implemented in the same way with Async/await . As for what if they come to replace BackgroundWorker the truth is that at the moment microsoft has not marked it as obsolete, but in this page specifies that for new developments the use of the Task-based Asynchronous Pattern (TAP) is recommended:

  

Asynchronous Programming Model (APM):   Describes the old model that uses the IAsyncResult interface to provide asynchronous behavior. This model is no longer recommended for new developments.

     

Event-based Asynchronous Pattern (EAP):   Describe the old model based on events to provide asynchronous behavior. This model is no longer recommended for new developments.

     

Task-based Asynchronous Pattern (TAP):   Describes the new asynchronous pattern based on the System.Threading.Tasks namespace. This model is the recommended approach for asynchronous programming in the .NET Framework 4 and later versions.

In short, I would not worry about modifying the code you already have using BackgroundWorker , but for any new development use Task with Async/await