Wie oft verwenden Sie System.Component.BackgroundWorker in Ihren Benutzeroberflächen? (wenn überhaupt)

Question

Ich bin mir sicher, dass eine reaktionsfähige Benutzeroberfläche etwas ist, nach dem jeder strebt, und die empfohlene Vorgehensweise ist, den BackgroundWorker dafür zu verwenden.

Findest du es einfach zu arbeiten? Benutzt du es oft? Oder haben Sie Ihre eigenen Frameworks für langwierige Aufgaben und Reporting-Prozesse?

Ich habe festgestellt, dass ich es ziemlich viel benutze und sogar seine Delegierten benutze, wo immer ich eine Art Fortschrittsbericht brauche.

Answer 1

Multithreaded Programmierung ist am Anfang schwer zu verstehen (und Veteranen immer noch manchmal scheitern) und BackgroundWorker macht es ein bisschen einfacher zu bedienen. Ich mag die Tatsache, dass BackgroundWorker Funktionalität hat, die leicht zu implementieren ist, aber noch einfacher auf subtile Art und Weise falsch implementiert werden kann, wie zum Beispiel die Löschung. Ich benutze es wenn ich ein Fortschritts-Update habe und brauche, damit ich einen aussagekräftigen Fortschrittsbalken anzeigen kann.

Wenn nicht, benutze ich einen Thread (oder entwerfe aus dem ThreadPool), weil ich nicht die ganze Funktionalität von BackgroundWorker benötige und mit Threads gekonnt genug bin, um einen Thread zu starten und darauf zu warten.

Wie Delegaten für nicht verwandte Aufgaben, verwende ich diejenigen der Thread-Klassen, wie einfach void ThreadStart(), oder ich erstelle meine eigenen.

Answer 2

Ich benutze es ziemlich oft für Aufgaben wie Fortschrittsanzeige und Hintergrunddaten laden \ Verarbeitung.
Kürzlich habe ich Use Case gefunden, die nicht von der Box unterstützt wird. Es ist "überschreibbare Aufgabe". Doch Patric Smacchia kommt mit netten solution.

Answer 3

BackgroundWorker macht die Dinge viel einfacher. Eine Sache, die ich auf die harte Tour fand, ist, dass der Backgroundworker selbst Thread-Affinität hat, obwohl er das Thread-Switching-Problem verbergen soll. Es wird nicht automatisch in jedem Fall zum UI-Thread gewechselt. Es muss erstellt und vom UI-Thread ausgeführt werden, damit die Thread-Umschaltung ordnungsgemäß ausgeführt wird.

Answer 4

Ich habe es einmal benutzt und war sehr zufrieden damit. Oft gibt es kein "großes" Multithreading, sondern nur 2 Threads (UI und Worker), und es funktioniert wirklich gut, ohne sich um die zugrundeliegende Threading Logic kümmern zu müssen.

Answer 5

@Gulzar Vielen Dank für diese Information: Sie muss erstellt und über den UI-Thread ausgeführt werden, damit der Threadwechsel richtig ausgeführt wird.

Eine Sache, auf die ich achten muss, wenn ich einen Hintergrundarbeiter verwende, ist Exception Handlings.

Wenn eine Ausnahme für den asynchronen Prozess ausgelöst wird, wird keine Ausnahme zum Hauptthread ausgelöst, der Prozess wird beendet und das HintergrundWorker RunWorkerCompleted-Ereignis wird ausgelöst, wobei der Fehler in RunWorkerCompletedEventArgs.Error ausgeblendet wird.

Ich mag die Tatsache, dass BackgroundWorker Funktionalität hat, die einfach zu implementieren ist, aber noch einfacher auf eine subtile Art und Weise falsch zu implementieren, wie die Löschung.

Answer 6

Mein größtes Problem mit der Hintergrundarbeiter Klasse ist, dass es wirklich keine Möglichkeit gibt zu wissen, wann der Arbeiter wegen der Kündigung fertig ist. Der BackgroundWorker stellt den verwendeten Thread nicht zur Verfügung, sodass Sie die Standardtechniken zum Synchronisieren der Thread-Beendigung (Join usw.) nicht verwenden können. Sie können auch nicht einfach in einer Schleife auf den Benutzeroberflächenthread warten, bis der Vorgang beendet wird, da das RunWorkerCompleted-Ereignis niemals zum Beenden führt. Der Hack, den ich immer verwenden musste, besteht darin, einfach ein Flag zu setzen und dann einen Timer zu starten, der weiterhin nach dem Ende des Hintergrundarbeiters sucht.Aber es ist sehr unordentlich und kompliziert die Geschäftslogik.

So ist es großartig, solange Sie nicht die deterministische Löschung unterstützen müssen.