我对 Metro 开发还很陌生,我只希望能够以一种可以理解的方式表达我的问题......
实际上,我正在将旧应用程序的一部分移植到 Metro。逻辑部分是一个单独的项目(可移植库),它应该服务于 1) 旧的 WPF 应用程序和 2) 新的 Metro 应用程序。基本逻辑是相同的,但某些子系统(例如文件操作管理器)必须以不同的方式编码 - 即 Metro 的异步方式。
我的问题是:我是否必须将调用者-被调用者的整个方法链重写为新的异步范例?假设我有 4 个方法链,从方法 A = Metro UI 事件异步处理程序开始(对我来说,将其编码为 async void 是有意义的,因为它是顶部的 fire&forget 事件),通过接下来的 2 个方法(B 和 C )放置在我的应用程序的不同层中,一直到包含“await CreateFileAsync”方法(由 Microsoft 设为异步)的方法 D。
现在:应使用await 调用异步CreateFileAsync 方法。这迫使我也将方法 D 设为异步。要从 C 调用方法 D,从 B 调用方法 C,从 A 调用方法 B - 我是否必须将所有 A、B 和 C 重写为异步等待样式?
我觉得我缺少更深入的知识,所以我正在努力自学,但同时我想在这里碰碰运气......
我必须重写大部分代码吗?我上面的说法有错误吗?
提前非常感谢,汉斯
最佳答案
我建议您将可移植库重写为异步。情况不像以前那么糟糕了; Microsoft 在 async
/await
方面付出了很大的努力,以尽可能轻松地将同步代码转换为异步代码。我预计在不久的将来,很多其他人也会做同样的事情,并且 R# 可能会实现“make async”重写。
混契约(Contract)步和异步代码时存在一些不明显的陷阱 - 请参阅 Stephen Toub 的上一篇博客文章 Should I expose synchronous wrappers for asynchronous methods?因此,我认为将异步操作公开为异步 API(将同步操作公开为同步 API)更加干净。
更新:如果您确实希望同步代码调用异步代码,那么您可以使用my AsyncEx library中的Task.WaitAndUnwrapException
扩展方法。 。但是,您仍然遇到 Stephen Toub 的帖子中提到的问题,即:
- 如果您的库没有在所有可以使用的地方使用
ConfigureAwait(false)
,则可能会出现死锁。 - 如果遇到线程池中的最大线程数,也可能会发生死锁。
(2) 不再常见,但 (1) 确实有可能。定期brought up由刚刚测试异步
的人开发,因此他们将其与同步代码混合在一起。
关于c# - Metro 应用程序中的异步调用链接,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10183179/