Определение, когда следует реализовать асинхронную модель, основанную на событиях

Обновлен: Ноябрь 2007

Асинхронная модель, основанная на событиях, предоставляет модель предоставления асинхронного поведения класса. При представлении этой модели .NET Framework определяет две модели для представления асинхронного поведения: асинхронную модель, основанную на интерфейсе System.IAsyncResult, и модель, основанную на событиях. В этом разделе описаны случаи, в которых применима реализация обоих моделей.

Дополнительные сведения об асинхронном программировании с помощью интерфейса IAsyncResult см. в разделе Шаблоны разработки для асинхронного программирования.

Общие принципы

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

Примечание.
Очень редко модель IAsyncResult реализуется без реализации модели, основанной на событиях.

Правила

В следующем списке описаны правила по реализации асинхронной модели, основанной на событиях:

• Используйте модель, основанную на событиях, в качестве интерфейса API по умолчанию для предоставления асинхронного поведения в классе.

• Не предоставляйте модель IAsyncResult, если класс используется, в основном, в клиентском приложении, например в Windows Forms.

• Предоставляйте модель IAsyncResult только в том случае, если это необходимо для выполнения требований. Например, для совместимости с существующим API может потребоваться предоставление модели IAsyncResult.

• Не предоставляйте модель IAsyncResult без предоставления модели, основанной на событиях.

• Если необходимо предоставить модель IAsyncResult, выполните это в качестве дополнительной возможности. Например, если был создан объект прокси, создайте модель, основанную на событиях, по умолчанию с возможностью создания модели IAsyncResult.

• Постройте собственную реализацию модели, основанной на событиях, для реализации модели IAsyncResult.

• Избегайте предоставления модели, основанной на событиях, и модели IAsyncResult в одном классе. Предоставьте модель, основанную на событиях, в классах более высокого уровня, а модель IAsyncResult в классах более низкого уровня. Например, сравните модель, основанную на событиях, в компоненте WebClient с моделью IAsyncResult в классе HttpRequest.

  • Предоставьте модель, основанную на событиях, и модель IAsyncResult для одного и того же класса, если это необходимо для совместимости. Например, если интерфейс API, использующий модель IAsyncResult, уже освобожден, необходимо оставить модель IAsyncResult для обратной совместимости.

  • Предоставьте модель, на основе события, и модель IAsyncResult для одного и того же класса, если сложность результирующей модели объекта превосходит преимущества разделения реализаций. Лучше предоставить обе модели в одном классе, чем избегать предоставления модели, основанной на событиях.

  • Если необходимо предоставить обе модели IAsyncResult и модели, основанной на событиях, используйте объект EditorBrowsableAttribute, заданный как Advanced, для отметки реализации модели IAsyncResult как дополнительной функциональной возможности. Это указывает средам проектирования, таким как Visual Studio IntelliSense, что не следует отображать свойства и методы IAsyncResult. Эти свойства и методы все еще можно использовать в полной мере, однако разработчик, работающий в IntelliSense, более ясно представляет интерфейс API.

Критерии предоставления модели IAsyncResult как дополнения к модели, основанной на событиях

Хотя асинхронная модель, основанная на событиях, имеет целый ряд преимуществ в сценариях, указанных выше, она содержит и ряд недостатков, о которых необходимо знать на тот случай, если производительность будет являться самым важным требованием.

Существует три случая, в которых модель, основанная на событиях, работает хуже, чем модель IAsyncResult:

• Блокировка ожидания для одного объекта IAsyncResult

• Блокировка ожидания на нескольких объектах IAsyncResult

• Запрос завершения для объекта IAsyncResult

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

Разработчики часто используют модель IAsyncResult для служб, требования к производительности которых очень высоки. Например, в случае запроса завершения используется высокопроизводительный сервер.

Кроме того, модель, основанная на событиях, менее эффективна по сравнению с моделью IAsyncResult, так как создает большее количество объектов, особенно EventArgs, и синхронизируется между потоками.

В следующем списке приведены некоторые рекомендации, которым стоит придерживаться, если необходимо использовать модель IAsyncResult:

• Предоставляйте модель IAsyncResult, только если напрямую необходима поддержка объектов WaitHandle or IAsyncResult.

• Предоставляйте шаблон IAsyncResult только при наличии интерфейса API, который использует IAsyncResult.

• Если имеется интерфейс API, основанный на модели IAsyncResult, рассмотрите возможность предоставления модели, основанной на событиях, в следующем выпуске приложения.

• Предоставляйте модель IAsyncResult, только если существуют требования к высокой производительности, которые не могут быть выполнены с помощью модели, основанной на событиях, а только с помощью модели IAsyncResult.

См. также

Задачи

Пошаговое руководство. Реализация компонента, поддерживающего асинхронную модель, основанную на событиях

Основные понятия

Реализация асинхронной модели, основанной на событиях

Рекомендации по реализации асинхронной модели, основанной на событиях

Обзор асинхронной модели, основанной на событиях

Другие ресурсы

Шаблоны разработки для асинхронного программирования

Многопоточное программирование с использованием асинхронной модели, основанной на событиях