我一直在教自己异步/等待使用,我想我理解了引擎盖下的概念.但是,在async/await上的大多数Channel 9教程,MSDN文章和Stack溢出答案都使用基于GUI的应用程序(Windows Forms应用程序)来演示async/await的强大功能.
但是,我注意到基于UI线程的应用程序与常规ThreadPool基于线程的应用程序(例如ASP.NET Web应用程序,控制台应用程序等)中async/await使用的根本区别.
因为,在基于UI线程的应用程序中,UI线程始终可用(除非进程显式或由Windows停止),因此负责在任何异步方法中"等待"之后执行代码的ThreadPool线程将保证找到UI线程将结果发回(如果有的话).
但是,在控制台应用程序或ASP.NET Web应用程序中,主线程(在控制台应用程序中)或HTTP请求(在ASP.NET Web应用程序中)必须等待(在一个时间点),直到所有异步操作都是完成.所以在Async方法调用之后应该有.Wait()和.Result调用,如果没有其他工作可以处理的话.
这种理解是否正确？我并没有质疑对I/O绑定或网络绑定操作进行异步的好处(我理解它将如何提高应用程序的可伸缩性).
在网站上搜索后,我发布了这个问题.我知道默认程序集是"文化中立"的,并且可以创建仅包含具有文化特定信息的资源(而不是代码)的附属程序集,并将它们放在与文化名称相同的文件夹中(即en-us) .但问题是,什么是文化？一些特定的现实例子会有所帮助.
我的MVC应用程序使用库,此库的一些方法在内部调用WCF服务.从此DLL公开的所有方法都是同步的(它们都没有返回任务或任务),因为我们不拥有该程序集,所以无法将它们转换为异步API.
但是,因为这些方法调用WCF服务,所以它们是网络绑定的(因此理想情况下它们应该是异步的).
我想在我的MVC应用程序中使用异步控制器操作,以使其更具可伸缩性.我的问题是当一个方法本质上是同步时,如何使整个方法管道等待.
异步操作 - >等待异步方法 - >等待异步方法2 - >库中的同步方法？
我应该使用TaskCompletionSource还是Task.FromResult来包装库方法调用？
另外,如果我使用上述方法,我的代码会比同步版本更具可扩展性吗？