Metro应用程序中的异步呼叫链接 [英] Async calls chaining in Metro app

问题描述

我对Metro开发人员还很陌生，我只希望我能够以一种可以理解的方式表达我的问题...

I am quite new to Metro dev and I only hope I will be able to express my question in an understandable way...

实际上，我正在将旧应用程序的一部分移植到Metro.逻辑部分是一个单独的项目(便携式库)，它应用于1)旧的WPF应用程序和2)新的Metro应用程序.基本逻辑是相同的，但某些子系统(例如文件操作管理器)必须采用不同的编码方式-即Metro的异步方式.

Actually I am porting a part of my old application to Metro. The logic part is a separated project (Portable Library) and it should serve to 1) the old WPF app and 2) the new Metro app. The basic logic is the same but some subsystems (for example file operations manager) must be coded differently - i.e. async way for Metro.

我的问题是:我是否必须将整个方法调用方-被调用方链重写为新的异步范例?假设我有4种方法链，从方法A = Metro UI事件异步处理程序开始(对我来说，将其编码为异步void是有意义的，因为它是最主要的fire&忘记事件)，然后是接下来的2种方法(B和C)放在应用程序的不同层中，一直到方法D包含"await CreateFileAsync"方法(由Microsoft进行异步处理).

My question is: Do I have to rewrite the whole chain of methods caller-callee to the new async paradigm? Let's say I have a chain of 4 methods, starting by method A = Metro UI event async handler (it makes sense to me to code it as async void as it is the top fire&forget event), through the next 2 methods (B and C) placed in different layers of my application, down to the method D containing "await CreateFileAsync" method (made async by Microsoft).

现在:异步CreateFileAsync方法应与await一起调用.这也迫使我使方法D异步.要从C调用方法D，从B调用B的方法C，从A调用B的方法-我必须将所有A，B和C重写为异步等待样式吗?

Now: async CreateFileAsync method should be called with await. That forces me to make method D async too. To call method D from C and C from B and B from A - do I have to rewrite all A, B and C into the async-await style?

我可以感觉到我缺少更深入的知识，所以我想对自己进行教育，但同时我想在这里尝试一下自己的运气...

I can feel I am missing a deeper knowledge so I am trying to educate myself but concurrently I wanted to try my luck here...

我是否需要重写大部分代码?我上面的任何陈述是错误的吗?

Do I have to rewrite a big part of my code? Is any of my statements above wrong?

提前感谢，汉斯

推荐答案

我建议您重写可移植库以使其异步.它不像以前那样糟糕. Microsoft在async/await上进行了非常艰苦的工作，以尽可能轻松地将同步代码转换为异步代码.我希望在不久的将来会有很多其他人这样做，并且R#可能会实现"make async"重写.

I recommend that you do rewrite your portable library to be asynchronous. It's not as bad as it used to be; Microsoft worked very hard on async/await to make it as easy as possible to convert synchronous code to asynchronous. I expect that a whole lot of others will be doing the same in the near future, and R# will probably implement a "make async" rewriting.

混合同步代码和异步代码时存在明显的陷阱-请参阅Stephen Toub的最新博客文章

There are non-obvious pitfalls when mixing synchronous and asynchronous code - see Stephen Toub's last blog post Should I expose synchronous wrappers for asynchronous methods? For this reason, I think it's just cleaner to expose asynchronous operations as asynchronous APIs (and synchronous operations as synchronous APIs).

更新:如果您确实希望同步代码调用异步代码，则可以在Task.WaitAndUnwrapException扩展方法. ="nofollow">我的AsyncEx库.但是，您仍然有Stephen Toub的帖子中提到的问题，即:

Update: If you do want synchronous code to call asynchronous code, then you can use the Task.WaitAndUnwrapException extension method in my AsyncEx library. However, you still have the problems mentioned in Stephen Toub's post, namely these:

1. 如果您的库没有在所有可能的地方使用ConfigureAwait(false)，则可以死锁.
2. 如果遇到线程池中的最大线程数，也可能会死锁.

1. You can deadlock if your library doesn't use ConfigureAwait(false) everywhere it can.
2. You can also deadlock if you run into the maximum number of threads in the thread pool.

(2)不再那么常见了，但是(1)确实有可能.经常由刚刚测试async的人开发出来的，所以他们将其与同步代码混合在一起.

(2) is not that common anymore, but (1) is a real possibility. It's regularly brought up by people who are just testing out async so they mix it with synchronous code.

这篇关于Metro应用程序中的异步呼叫链接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！