Как часто вы используете System.Component.BackgroundWorker в своих интерфейсах? (если даже)

Question

Я уверен, что отзывчивый пользовательский интерфейс - это то, к чему все стремятся, и рекомендуемый способ сделать это - использовать BackgroundWorker для этого.

С тобой легко работать? Вы часто используете это? Или у вас есть свои собственные структуры для длительных задач и процесса отчетности.

Я обнаружил, что использую его довольно часто и даже использую его делегаты везде, где мне нужны какие-то отчеты о прогрессе.

Answer 1

Многопоточное программирование трудно поначалу понять (а ветераны иногда терпят неудачу), а BackgroundWorker делает его немного проще в использовании. Мне нравится тот факт, что BackgroundWorker обладает функциональностью, которая проста в реализации, но даже легче ошибочно реализовать тонким способом, таким как отмена. Я использую его, если у меня есть и мне нужно обновление прогресса, чтобы я мог отображать значимый индикатор выполнения.

Если нет, я использую Thread (или заимствуюсь у ThreadPool), потому что мне не нужны все функции BackgroundWorker, и я достаточно опытен с потоками, чтобы запустить Thread и ждать его остановки.

Что касается делегатов для несвязанных задач, я использую те из классов Thread, как обычный void ThreadStart(), или создаю свои собственные.

Answer 2

BackgroundWorker делает все намного проще. Одна сложность, которую я нашел, заключается в том, что сам Backgroundworker имеет сходство с потоками, даже если предполагается, что он скрывает проблему переключения потоков. Он не переключается автоматически на поток пользовательского интерфейса в каждом случае. Его необходимо создать и запустить из потока пользовательского интерфейса, чтобы переключение потоков происходило правильно.

Answer 3

Я использовал его один раз и был очень доволен этим. Зачастую нет необходимости в «большой» многопоточности, а только для 2 потоков (пользовательский интерфейс и рабочий), и это работает очень хорошо, не нужно слишком беспокоиться о базовой логике потоков.

Answer 4

Я использую его довольно часто для таких задач, как индикация прогресса и фоновая загрузка / обработка данных.
Недавно я нашел вариант использования, который не поддерживается из коробки. Это «Переопределенная задача». Однако Патрик Смаккья придумал хорошее решение .

Answer 5

Моя самая большая проблема с фоновым рабочим классом заключается в том, что на самом деле нет способа узнать, когда работник закончил работу из-за отмены. BackgroundWorker не предоставляет поток, который он использует, поэтому вы не можете использовать стандартные методы для синхронизации завершения потока (объединение и т. Д.). Вы также не можете просто ждать в цикле потока пользовательского интерфейса, чтобы он завершился, потому что событие RunWorkerCompleted никогда не закончится срабатыванием. Хак, который я всегда использовал, состоит в том, чтобы просто установить флаг и затем запустить таймер, который продолжит проверку на завершение фонового рабочего. Но это очень грязно и усложняет бизнес-логику.

Так что это здорово, если вам не нужно поддерживать детерминированное аннулирование.

Answer 6

@ Gulzar Спасибо за эту информацию: ее необходимо создать и запустить из потока пользовательского интерфейса, чтобы переключение потоков происходило правильно.

Одна вещь, на которую нужно обратить внимание при использовании фонового работника, который я обнаружил, - это обработка исключений.

Если в асинхронном процессе возникнет исключение, оно не вызовет исключение в основном потоке, процесс завершится, и сработает событие BackgroundWorker RunWorkerCompleted с ошибкой, скрытой в RunWorkerCompletedEventArgs.Error.

Мне нравится тот факт, что BackgroundWorker обладает функциональностью, которая проста в реализации, но даже легче ошибочно реализовать тонким способом, таким как отмена.