Compartir a través de

Decidir cuándo implementar el patrón asincrónico basado en eventos

El patrón asincrónico basado en eventos proporciona un patrón para exponer el comportamiento asincrónico de una clase. Con la introducción de este patrón, .NET define dos patrones para exponer el comportamiento asincrónico: el patrón asincrónico basado en la System.IAsyncResult interfaz y el patrón basado en eventos. En este artículo se describe cuándo es adecuado implementar ambos patrones.

Para obtener más información sobre la programación asincrónica con la IAsyncResult interfaz, vea Modelo de programación asincrónica (APM).

Principios generales

En términos generales, debe exponer funciones asincrónicas mediante el patrón asincrónico basado en eventos siempre que sea posible. Sin embargo, hay algunos requisitos que el patrón basado en eventos no puede cumplir. En esos casos, es posible que tenga que implementar el IAsyncResult patrón además del patrón basado en eventos.

Nota:

Es poco frecuente que el IAsyncResult patrón se implemente sin que también se implemente el patrón basado en eventos.

Directrices

En la lista siguiente se describen las directrices para cuándo debe implementar el patrón asincrónico basado en eventos:

  • Use el patrón basado en eventos como la API predeterminada para exponer el comportamiento asincrónico de la clase.

  • No exponga el IAsyncResult patrón cuando la clase se use principalmente en una aplicación cliente, por ejemplo, Windows Forms.

  • Exponga solo el IAsyncResult patrón cuando sea necesario para cumplir sus requisitos. Por ejemplo, la compatibilidad con una API existente puede requerir que exponga el IAsyncResult patrón.

  • No exponga el IAsyncResult patrón sin exponer también el patrón basado en eventos.

  • Si debe exponer el IAsyncResult patrón, hágalo como una opción avanzada. Por ejemplo, si genera un objeto proxy, genere el patrón basado en eventos de forma predeterminada, con una opción para generar el IAsyncResult patrón.

  • Construya su implementación de patrón basada en eventos sobre su implementación de patrón IAsyncResult.

  • Evite exponer tanto el patrón basado en eventos como el IAsyncResult patrón en la misma clase. Exponga el patrón basado en eventos en clases de "nivel superior" y el IAsyncResult patrón en clases de "nivel inferior". Por ejemplo, compare el patrón basado en eventos en el WebClient componente con el IAsyncResult patrón en la HttpRequest clase .

    • Exponga el patrón basado en eventos y el IAsyncResult patrón en la misma clase cuando la compatibilidad lo requiera. Por ejemplo, si ya ha publicado una API que usa el IAsyncResult patrón, tendría que conservar el IAsyncResult patrón para la compatibilidad con versiones anteriores.

    • Exponga el patrón basado en eventos y el IAsyncResult patrón en la misma clase si la complejidad del modelo de objetos resultante supera la ventaja de separar las implementaciones. Es mejor exponer ambos patrones en una sola clase que evitar exponer el patrón basado en eventos.

    • Si debe exponer tanto el patrón basado en eventos como el patrón IAsyncResult en una sola clase, use EditorBrowsableAttribute configurado como Advanced para marcar la implementación del patrón IAsyncResult como una característica avanzada. Esto indica a los entornos de diseño, como IntelliSense de Visual Studio, que no muestren las IAsyncResult propiedades y métodos. Estas propiedades y métodos siguen siendo totalmente utilizables, pero el desarrollador que trabaja a través de IntelliSense tiene una vista más clara de la API.

Criterios para exponer el patrón IAsyncResult además del patrón basado en eventos

Aunque el patrón asincrónico basado en eventos tiene muchas ventajas en los escenarios mencionados anteriormente, tiene algunas desventajas, que debe tener en cuenta si el rendimiento es su requisito más importante.

Hay tres escenarios que el patrón de eventos no aborda tan bien como el patrón IAsyncResult.

Puede abordar estos escenarios mediante el patrón basado en eventos, pero hacerlo es más complicado que usar el IAsyncResult patrón.

Los desarrolladores suelen usar el IAsyncResult patrón para los servicios que normalmente tienen requisitos de rendimiento muy altos. Por ejemplo, el sondeo para el escenario de finalización es una técnica de servidor de alto rendimiento.

Además, el patrón basado en eventos es menos eficaz que el IAsyncResult patrón porque crea más objetos, especialmente EventArgs, y porque se sincroniza entre subprocesos.

En la lista siguiente se muestran algunas recomendaciones que se deben seguir si decide usar el IAsyncResult patrón :

  • Exponga solo el IAsyncResult patrón cuando necesite específicamente compatibilidad con WaitHandle objetos o IAsyncResult .

  • Exponga solo el IAsyncResult patrón cuando tenga una API existente que use el IAsyncResult patrón .

  • Si tiene una API existente basada en el IAsyncResult patrón, considere también la posibilidad de exponer el patrón basado en eventos en la próxima versión.

  • Exponga el patrón IAsyncResult solo si tiene requisitos de alto rendimiento que ha comprobado no pueden ser cumplidos por el patrón basado en eventos, pero sí por el patrón IAsyncResult.

Consulte también