BackgroundWorker vs Async / Await


16

Soy nuevo en el desarrollo de C # y deseo crear una interfaz de usuario más receptiva. En mi investigación preliminar, he visto dos métodos para lograr esto:

  1. Multi-threading junto con la clase BackgroundWorker.
  2. Los nuevos modificadores Async / Await.

¿Más nuevo significa mejor? ¿Cuál es la diferencia entre los dos métodos? Si deseo crear un nuevo proyecto, ¿cómo elijo qué método utilizar?

EDITAR: Tal vez debería especificar. Estoy creando una aplicación de Windows Forms, donde todos los datos necesarios se guardarán / cargarán en el disco local. También me comunicaré con varios dispositivos USB.


Respuestas:


10

Podrá realizar su tarea utilizando BackgroundWorker. Es una clase bien conocida, y muchas personas la han usado.

El nuevo C # 5 asyncy las awaitpalabras clave básicamente hacen que sea más fácil escribir código asincrónico legible. Puede haber menos tutoriales y ejemplos de cómo realizar diversas tareas con estas palabras clave en lugar de hacerlo BackgroundWorker.

A menos que necesite usar una versión anterior de C #, le sugiero que aprenda a usar asyncy await.


13

Los asyncy awaitlas palabras clave no hará que su aplicación más sensibles por su propia cuenta. Simplemente hacen que la llamada y el manejo de métodos que devuelven Taskobjetos sean más convenientes. Para hacer async/ awaitusar hilos de fondo, necesitará combinarlos con el uso de cosas como:

  • Task.Start()- Inicia una tarea determinada usando el TaskScheduler.
  • PLINQ: ejecuta una serie de operaciones en paralelo, devuelve una tarea.
  • TaskCompletionSource- Una forma personalizada de manejar tareas asíncronas. Un lugar en el que usé esto fue para manejar eventos provenientes de un WebBrowsercontrol.
  • Otros asyncmétodos, como muchas de las funciones en la API de Win 8.

En otras palabras, async/ awaites una extensión del patrón asincrónico basado en tareas . Puede encontrar una gran cantidad de información, incluidas muchas muestras, aquí .

El BackgroundWorkeres un componente WinForms que crea 1 subproceso en segundo plano utilizando el patrón asíncrono basado en eventos , y puede completar el trabajo realizado en este subproceso en segundo plano con su propio código en el DoWorkcontrolador de eventos. En general, Microsoft ya no recomienda usar este patrón (consulte la parte inferior de la página aquí ), aunque si ya está familiarizado con él, puede ser una opción simple.

Otra opción no mencionada son las extensiones reactivas para .NET . Este es otro gran marco para agregar capacidad de respuesta a sus aplicaciones.


Cuando dice Win 8 API, ¿eso implica que las características de Async no son tan compatibles con Windows 7 (mi plataforma de destino)?
robert.ecot

1
Hola Robert, la API de Win 8 .NET (para aplicaciones de estilo "Metro") que utiliza asíncrona y espera mucho para todo, desde E / S de archivos hasta mostrar cuadros de diálogo. En otros componentes .NET, por ejemplo, FileStream, también puede usar async / await con métodos como Stream.ReadAsync. Por lo tanto, también hay algo de soporte fuera de Win 8.
Kevin McCormick

¡Genial, y gracias por los enlaces actualizados también! Muy útil.
robert.ecot

1
No veo nada en esa página que indique que BackgroundWorker, específicamente, se recomienda no hacerlo .
Kyralessa

También recomiendo la lectura de Async VS BackgroundWorker y la serie de publicaciones de blog sobre programación concurrente en C # de Stephen Clearly, autor del libro omónimo publicado por O'Reilly.
sentencia el

3

Yo diría que async- awaites mucho más flexible que BackgroundWorker. Y si usted quiere hacer algo que se adapte BackgroundWorker, puede hacerlo con async- awaittambién, con el código de seguridad de tipos más legible y más.

Debido a eso, creo que debería preferir usar async- awaitover BackgroundWorker.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.