Обновление компонентов пользовательского интерфейса от асинхронного обратного вызова

Question

Теперь я знаю о диспетчере и DispatcherTimer и их преимуществах. Но у меня всегда создалось впечатление, что обратный вызов async web-service/WCF (обработчик обработанного события) автоматически обрабатывается потоком пользовательского интерфейса.

Но, глядя на некоторые ссылки в Интернете, например, на приведенный ниже, кажется, что это не так.

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

Может ли кто-нибудь объяснить, почему я не видел это исключение, или подтвердите, правильно ли мое первоначальное предположение?

Ссылка: http://www.silverlightshow.net/items/Tip-Asynchronous-Silverlight-Execute-on-the-UI-thread.aspx

Answer 1

Что диспетчеру сделать, это положить сообщение в нормальное окна сообщений queuse. Если вы обновляете элемент, привязанный к элементу пользовательского интерфейса, вам не нужно использовать диспетчера, потому что PropertyChanged, поднятый при обновлении вашей модели, уже отправил сообщение в очередь сообщений Windows, поэтому вам не нужно вызывать диспетчера, иначе вы просто совершаете две круглые поездки в очередь оконных сообщений.

Answer 2

Простейшее объяснение это зависит от того, как вы извлекаете данные и хотите ли вы обновить интерфейс. Например, при непосредственном использовании HttpWebRequest его всегда нужно перевести обратно в поток пользовательского интерфейса. Однако, если вы используете WebClient, это делается для вас. WCF также сделает некоторые маршалинги для вас.

«Прокси WCF в приложениях Silverlight используют SynchronizationContext потока, из которого инициируется вызов веб-службы, чтобы запланировать вызов обработчика событий async при получении ответа».

http://tomasz.janczuk.org/2009/08/improving-performance-of-concurrent-wcf.html

Другими словами, WCF мобилизует вызов обратно в поток, в котором он был вызван. Поэтому, если вы вызываете свои служебные вызовы из потока пользовательского интерфейса, они возвращаются к потоку пользовательского интерфейса. Если вы вызываете свои службы в другом потоке, вам нужно будет сделать маршалинг самостоятельно.

Надеюсь, что это поможет.