我觉得如果许多类(例如TcpClient
, UdpClient
, HttpListener
)是事件驱动的,它们会更容易理解和使用。而且IAsyncResult
模式非常难以实现,因为它会为您打开各种奇怪的用例:
- 如果调用者连续调用多个 Begin 方法怎么办?
- 如果调用者混合了 Begin 和常规方法怎么办?
等等。尽管如此,微软还是选择在大多数地方使用它。为什么?
编辑:请将讨论集中在 .NET 2.0 上,因为这是我必须使用的。
我觉得如果许多类(例如TcpClient
, UdpClient
, HttpListener
)是事件驱动的,它们会更容易理解和使用。而且IAsyncResult
模式非常难以实现,因为它会为您打开各种奇怪的用例:
等等。尽管如此,微软还是选择在大多数地方使用它。为什么?
编辑:请将讨论集中在 .NET 2.0 上,因为这是我必须使用的。
等等。尽管如此,微软还是选择在大多数地方使用它。为什么?
使用的异步模式IAsyncResult
是框架中使用的原始异步编程模式。它没有什么优势,而且随着时间的推移,复杂性导致新模式的开发。
事件异步编程 (EAP) 是稍后介绍的(您有一个带有完成事件的“开始”方法)。这解决了很多复杂性,但在许多情况下仍然难以使用,因为您仍然必须将逻辑拆分为多个方法。
但是,当前的异步模式基于 .NET 4Task
和Task<T>
类,并提供了巨大的优势,尤其是在与 C# 5 的 async/await 支持结合使用时。幸运的是,TaskFactory.FromAsync可用于轻松地将IAsyncResult
基于异步方法对包装到Task<T>
自动中,因此可以使用新模式。.NET 4.5 添加了许多框架异步方法的新版本,这些方法返回Task<T>
,因此新的async
/await
语言支持可以与框架方法一起使用。这是所有异步编程的首选方法。
这种模式没有太多优势。
在 .Net 1.0 中,在泛型和 lambda 表达式之前,这是唯一可用的异步模式。
出于多种原因,更现代的基于任务的模式要好得多,包括类型安全、更简单的错误处理、延续、When*()
方法等。