Обеспечение того, чтобы все выполнялось в потоке пользовательского интерфейса в WPF

Я создаю приложение WPF. Я выполняю асинхронную связь с серверной частью, и я использую агрегацию событий с Prism на клиенте. Обе эти вещи приводят к появлению новых потоков, которые не являются потоком пользовательского интерфейса. Если я попытаюсь выполнить "операции WPF" в этих потоках обратного вызова и обработчика событий, мир распадается, и теперь он начал делать.

Сначала я встретил проблемы с попыткой создать некоторые объекты WPF в обратном вызове с сервера. Мне сказали, что поток нужен для запуска в режиме STA. Теперь я пытаюсь обновить некоторые данные пользовательского интерфейса в обработчике событий Prism, и мне сказали, что:

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

Итак, Какой ключ к правильному использованию WPF? Я прочитал в Диспетчере WPF в этот пост MSDN. Я начинаю это делать, но пока я еще не волшебник.

  • Является ли ключ всегда использовать Dispatcher.Invoke, когда мне нужно запустить что-то, что я не уверен, будет вызван в потоке пользовательского интерфейса?
  • Неважно, действительно ли он был вызван в потоке пользовательского интерфейса, и я все равно Dispatcher.Invoke?
  • Dispatcher.Invoke = синхронно. Dispathcher.BeginInvoke = async?
  • Будет ли Dispatcher.Invoke запрашивать поток пользовательского интерфейса, а затем перестать его ждать? Это плохая практика и риск менее гибких программ?
  • Как мне получить диспетчер? Будет ли Dispatcher.CurrentDispatcher всегда давать мне диспетчер, представляющий поток пользовательского интерфейса?
  • Будет ли более одного диспетчера или "Диспетчер" в основном такой же, как поток пользовательского интерфейса для приложения?
  • А какая сделка с BackgroundWorker? Когда я использую это вместо этого? Я предполагаю, что это всегда асинхронно?
  • Будет ли запущено все, что работает в потоке пользовательского интерфейса (путем вызова), в режиме квартиры STA? То есть если у меня есть что-то, что требуется для запуска в режиме STA - будет ли Dispatcher.Invoke достаточно?

Кто-нибудь хочет очистить вещи для меня? Любые соответствующие рекомендации и т.д.? Благодарю!

Ответы

Ответ 1

Переходя по каждому из ваших вопросов, один за другим:

  • Не совсем; вы должны только ссылаться на поток пользовательского интерфейса, когда это необходимо. См. № 2.
  • Да, это имеет значение. Вы не должны просто автоматически Invoke все. Ключ должен при необходимости только ссылаться на поток пользовательского интерфейса. Для этого вы можете использовать метод Dispatcher.CheckAccess.
  • Это правильно.
  • Также правильно, и да, вы рискуете менее гибкими программами. В большинстве случаев вы не увидите серьезный удар производительности (мы говорим о миллисекундах для контекстного переключателя), но при необходимости вы должны Invoke. При этом в некоторых случаях это неизбежно, поэтому нет, я бы не сказал, что это плохая практика. Это всего лишь одно решение проблемы, с которой вы будете сталкиваться время от времени.
  • В каждом случае, который я видел, я выполнил с помощью Dispatcher.CurrentDispatcher. Для сложных сценариев этого может быть недостаточно, но я (лично) их не видел.
  • Не совсем правильно, но эта линия мышления не принесет никакого вреда. Позвольте мне сказать так: Dispatcher может использоваться для доступа к потоку пользовательского интерфейса для приложения. Но это не сам по себе поток пользовательского интерфейса.
  • BackgroundWorker обычно используется, когда у вас есть трудоемкая операция и вы хотите поддерживать отзывчивый интерфейс при выполнении этой операции в фоновом режиме. Обычно вы не используете BackgroundWorker вместо Invoke, а используете BackgroundWorker вместе с Invoke. То есть, если вам нужно обновить некоторый объект пользовательского интерфейса в BackgroundWorker, вы можете вызвать в поток пользовательского интерфейса, выполнить обновление и вернуться к исходной операции.
  • Да. Потоки пользовательского интерфейса приложения WPF по определению должны работать в однопоточной квартире.

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