Почему Silverlight добавляет сервис Ref. использовать события вместо IAsyncResult?

Question

Ye Olde Add Web Reference генерирует вызовы XXXAsync к службам, которые используют события, чтобы сообщить вызывающему абоненту о завершении вызова.

Добавить ссылку на службу в чем-то похожем на WPF или консольное приложение, когда ему приказывают генерировать асинхронные операции, использует шаблон проектирования IAsyncResult (операции BeginXXX и EndXXX).Насколько я понимаю, это обычно рассматривается как шаг вперед в удобстве использования и гибкости - вы можете использовать обратный вызов, вы можете начать блокировку в любой момент времени, просто вызвав EndXXX, вы можете сгруппировать дескрипторы ожидания и блокировать набор операций,можно опросить и т. д.

Почему ASR в Silverlight не использует IAsyncResult?Я предполагаю, потому что дизайнеры хотели прояснить, что на самом деле требуется полная асинхронность, и если бы они использовали шаблон проектирования IAsyncResult, было бы слишком легко попробовать просто сразу вызвать Begin, а затем End, чтоза камень преткновения, который был бы затронут примерно 100% новых разработчиков или людей, которые плохо разбирались в асинхронности.

Answer 1

Команда Silverlight предоставила немедленный доступ к асинхронному шаблону на основе событий, потому что это более простой в использовании подход (но гораздо менее гибкий). Например, событие вызывается в потоке отображения, что позволяет разработчикам, не желающим думать о своей модели потока, забыть об этом.

Если вам нужна большая гибкость (как у меня), асинхронный шаблон Begin / End также доступен для Silverlight. Фактически сгенерированный код, основанный на событиях, основан на IAsyncResult.

Ваш сгенерированный интерфейс Channel определяет методы начала / конца, и вы можете использовать фабрику каналов для получения полезной реализации интерфейса.

Answer 2

С MSDN :

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

Иногда вам может потребоваться обработка события завершения в фоновом потоке. Либо по этой, либо по другим причинам вы можете использовать альтернативную модель асинхронного вызова, основанную на механизме IAsyncResult и методах Begin / End.

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

CopyIAsyncResult iar = ((CustomerService)proxy).BeginGetUser(userId, GetUserCallback, proxy);

Спасибо Кимберли за ссылку MSDN.