针对非异步服务的异步编程
本文关键字：异步 编程 服务 | 更新日期: 2023-09-27 18:00:02
在过去的一年里，我们一直在开发一款新的web应用程序，该应用程序可以调用我们公司现有的服务层。
我们决定将所有面向服务的调用打包到我们自己的服务层（我将其称为web服务层）中，这样我们使用的服务的细节（我们将在未来的某个时候转移到新的API）就不会被web层本身隐藏了。
我们还决定，我们的大多数web服务层方法将返回Task<T>。
目前，我们调用的底层服务不是异步的，因此有人担心，当我们有大量用户时，我们的web服务层会使可用线程最大化，并导致问题。
我正在以某种方式寻找信息，以进一步了解我们退货Task<T>的决定将如何影响我们的网站，以及我们是否需要考虑更改退货类型。
我们将在某个时候转到VS2012，但现在我们使用的是VS2010，而不是async和await。
目前，我们调用的底层服务不是异步的因此，有人担心我们的web服务层会将当我们有大量的用户。
是的，这是你应该关心的事情。我建议您只有在有真正的异步方法的情况下才这样做。但是，简单地将阻塞同步方法包装到异步API中将比直接从消费代码调用同步方法更糟糕。在ASP.NET应用程序中，只有当基础API依赖于I/O完成端口时，您才能从异步调用中获益。否则就是浪费资源。
可以做到这一点的唯一有用的场景是，可以并行调用方法，而不是顺序调用方法。这是可能的，只是不同的方法之间没有联系。在这种情况下，您确实可以将同步方法封装在异步任务中。