Второстепенный Рабочий C# winform
действительно ли это - плохая идея загрузить все в от второстепенного рабочего?? Текущий код Выполнен на Form_load. мы вытягиваем много данных из веб-сервиса. некоторые длительные работы находятся во второстепенном рабочем.
это была бы плохая идея загрузить все от второстепенного рабочего, неважно, насколько маленький или большой код?? каждая функция для выполнения во второстепенном рабочем? или эта попытка сделать этот код грязным и шагающим кошмаром.
Спасибо.
7 ответов
Размер кода не является показателем, который вы должны использовать, чтобы определить, выполнять ли работу в отдельном потоке. В наихудшем случае продолжительность казни составляет.
Во-первых, не так много дизайнов пользовательского интерфейса, в которых действительно желательно запускать кучу работы над Form_Load. Если возможно, я обычно либо:
- Начинаю эту работу до открытия формы, непосредственно в ответ на действие пользователя.
- Перенести всю работу на задний план и асинхронно обновить (привязать?) Результаты к форме.
- Отложите работу до тех пор, пока пользователь специально не выполнит какое-либо действие, которое этого требует.
Ваши пользователи будут хотеть / ожидать, что ваши формы будут чрезвычайно быстрыми и отзывчивыми, независимо от того, сколько работы будет выполнено. Выполнение потенциально длительных операций во время Form_Load всегда приводит к плохому взаимодействию с пользователем.
BackgroundWorker - это только один механизм для асинхронного выполнения работы, существует множество других. Вы должны выбрать наиболее подходящий для каждой ситуации.
BackgroundWorker обычно используется для повышения отзывчивости пользовательского интерфейса Winforms. Вы можете использовать его для фоновой обработки в веб-приложении, но я этого не делаю; Я использую пул потоков в службе Windows.
Хорошо встраивать потенциально долго выполняющийся код в фоновый рабочий процесс, чтобы ваше приложение оставалось отзывчивым, но нет необходимости помещать все в качестве фонового рабочего.
Если ваш код вызывает веб-службу (или любую внешнюю систему, время ожидания которой может истекать) или делает что-то, что может занять больше нескольких секунд, то это будет хорошим кандидатом для включения в фоновый рабочий процесс. однако, если выполнение чего-либо постоянно занимает меньше секунды или около того, я бы, вероятно, не стал беспокоиться.
Фоновому исполнителю потребуется дополнительное время, чтобы создать и уничтожить поток для фонового рабочего. Если это небольшой фрагмент кода (с точки зрения обработки), возможно, будет быстрее использовать основной поток пользовательского интерфейса.
Если ключевым моментом является ремонтопригодность, возможно, решением может стать использование фоновых воркеров для обработки. Пользовательская структура, которая автоматически обрабатывает детали, может сделать код еще более удобным в сопровождении.
Это зависит от нескольких факторов:
- Количество маленьких / больших фрагментов кода - это повлияет на количество потоков, работающих одновременно.
- Важность скорости отклика и производительности для приложения
- Важность ремонтопригодности / масштабируемости для приложения.
Судя по вашей ссылке на «Page_Load», вы реализуете это в веб-форме ASP.NET. Если это так, и вы пытаетесь вызвать веб-службу асинхронно, вам следует использовать функции вызова службы Begin и End. Это особенно хорошо работает, если вам нужно вызывать несколько веб-сервисов одновременно, а не вызывать их по одному как синонимы.
Наслаждайтесь!
Хорошая это идея или нет, во многом зависит от специфики вашей проблемы. Вам нужно получить все данные за один вызов или вы можете сделать это независимыми частями?
Если это один большой длительный вызов веб-службы, то размещение его в потоке ничего для вас не сделает. Лучшим вариантом будет несколько независимых, длительно работающих фрагментов, для возврата которых требуется примерно одинаковое количество времени.
Кроме того, в веб-формах (поскольку вы упоминаете Page_Load) IIRC вы будете совместно использовать пул потоков с asp.net, и вы можете сделать ваше приложение менее отзывчивым в целом при некотором пороге одновременных запросов / пользователей.
Лично я бы не стал помещать код в рабочий поток, если только код, содержащий конкретный процесс, не мешал реагированию пользовательского интерфейса. Нет никаких причин, по которым я могу помещать все в рабочий поток. Обычно проблемы с отзывчивостью возникают только тогда, когда вы ждете внешнего ресурса, такого как веб-сервис (если только вы не вычисляете простые числа в Form_Load :-).
Если вы не изучали вызовы асинхронных веб-сервисов, я бы порекомендовал взглянуть на них. Асинхронные вызовы будут обрабатывать ваши потоки за вас - всегда хорошо.