ContexteWorker vs Async / Await


16

Je suis nouveau dans le développement C # et souhaite créer une interface utilisateur plus réactive. Dans mes recherches préliminaires, j'ai vu deux méthodes pour y parvenir:

  1. Multi-threading en conjonction avec la classe BackgroundWorker.
  2. Les nouveaux modificateurs Async / Await.

Est-ce que plus récent signifie mieux? Quelle est la différence entre les deux méthodes? Si je souhaite créer un nouveau projet, comment choisir la méthode à suivre?

EDIT: Je devrais peut-être préciser. Je crée une application Windows Forms, où toutes les données nécessaires seront enregistrées / chargées sur le disque local. Je communiquerai également avec plusieurs périphériques USB.


Réponses:


10

Vous pourrez accomplir votre tâche en utilisant BackgroundWorker. C'est une classe bien connue et beaucoup de gens l'ont utilisée.

Le nouveau C # 5 asyncet les nouveaux awaitmots clés facilitent simplement l'écriture de code asynchrone lisible. Il peut y avoir moins de didacticiels et d'exemples sur la façon d'accomplir diverses tâches avec ces mots clés plutôt que BackgroundWorker.

À moins que vous n'ayez besoin d'utiliser une ancienne version de C #, je suggère d'apprendre à utiliser asyncet await.


13

Les mots clés asyncet awaitne rendront pas votre application plus sensible à eux seuls. Ils facilitent simplement l'appel et la gestion des méthodes qui renvoient des Taskobjets. Afin de créer async/ awaitutiliser réellement des threads d'arrière-plan, vous devrez combiner avec l'utilisation de choses comme:

  • Task.Start()- Démarre une tâche donnée en utilisant le TaskScheduler.
  • PLINQ - Exécuter une série d'opérations en parallèle, renvoie une tâche.
  • TaskCompletionSource- Une façon personnalisée de gérer les tâches asynchrones. Un endroit où je l'ai utilisé était de gérer les événements provenant d'un WebBrowsercontrôle.
  • D'autres asyncméthodes, telles que la plupart des fonctions de l'API Win 8.

En d'autres termes, async/ awaitest une extension du modèle asynchrone basé sur les tâches . Vous pouvez trouver une grande quantité d'informations, y compris de nombreux échantillons, ici .

Il BackgroundWorkers'agit d'un composant WinForms qui crée 1 thread d'arrière-plan à l'aide du modèle asynchrone basé sur les événements , et vous pouvez remplir le travail effectué sur ce thread d'arrière-plan avec votre propre code dans le DoWorkgestionnaire d'événements. En général, Microsoft ne recommande plus d'utiliser ce modèle (voir le bas de la page ici ), bien que si vous le connaissez déjà, il puisse toujours être une option simple.

Une autre option non mentionnée est les extensions réactives pour .NET . Ceci est un autre excellent cadre pour ajouter de la réactivité à vos applications.


Lorsque vous dites API Win 8, cela signifie-t-il que les fonctionnalités Async ne sont pas aussi bien prises en charge sur Windows 7 (ma plate-forme cible)?
robert.ecot

1
Salut Robert, l'API Win 8 .NET (pour les applications de style "Metro") utilise async et attend beaucoup pour tout, des E / S de fichiers à l'affichage des boîtes de dialogue. Dans d'autres composants .NET, par exemple FileStream, vous pouvez également utiliser async / wait avec des méthodes telles que Stream.ReadAsync. Il existe donc également un support en dehors de Win 8.
Kevin McCormick

Super, et merci aussi pour les liens mis à jour! Très utile.
robert.ecot

1
Je ne vois rien sur cette page qui indique que BackgroundWorker, spécifiquement, est déconseillé.
Kyralessa

Je recommande également la lecture d' Async VS BackgroundWorker et du série d'articles de blog sur la programmation simultanée en C # de Stephen Clearly, l'auteur du livre anonyme publié par O'Reilly.
sentenza

3

Je dirais que async- awaitest beaucoup plus flexible que BackgroundWorker. Et si vous voulez faire quelque chose qui vous convient BackgroundWorker, vous pouvez le faire avec async- awaitaussi, avec un code plus lisible et plus sûr.

Pour cette raison, je pense que vous devriez préférer utiliser async- awaitplutôt que BackgroundWorker.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.