考虑一个基本的WPF业务线应用程序，其中服务器和客户端都在本地网络上运行。服务器只是公开客户机(在桌面计算机上运行)调用的Web API。UI将由crud风格的屏幕组成，这些屏幕带有触发对服务器调用的按钮。
在我最初的应用版本中，这些UI操作都不是异步的;UI将在调用期间冻结。但没有人抱怨UI变得无响应，也没有人注意到;通话时间通常不到四分之一秒。在极少数情况下，如果网络连接断开，UI将冻结，直到操作超时，这是唯一一次引起注意的时间。
现在我已经开始为所有服务器调用实现async/await，很快就发现我手上有一个新问题:处理重入和取消的复杂性。从理论上讲，现在用户可以在呼叫已经进行时点击任何按钮。它们可以发起与挂起的操作冲突的操作。它们可能无意中创建无效的应用程序状态。他们可以导航到另一个屏幕或注销。现在，所有这些以前不可能发生的情况都必须得到解释。
我好像打开了潘多拉的盒子。
我将此与我以前的非异步设计进行对比，在非异步设计中，UI将在服务器调用期间锁定，并且用户可以简单地不单击任何。这保证了他们不会搞砸任何东西，从而使应用程序代码保持至少10倍的简单性。那么，所有这些现代异步无处不在的方法真正获得了什么呢?我敢打赌，如果用户将同步版本和异步版本并排比较，他们甚至不会注意到异步版本的任何好处;呼叫是如此之快，忙碌指示器甚至没有时间渲染。这似乎是一大堆额外的工作，复杂，难以维护的代码，几乎没有好处。我听到KISS原则在呼唤…我错过了什么?在LOB应用程序场景中，异步保证额外工作的好处是什么?
那么所有这些现代异步无处不在的方法真正获得了什么呢?
你已经知道答案了:async对UI应用程序的主要好处是响应性。(async在服务器端的主要优点是可伸缩性，但这里没有涉及到)。
如果你不需要响应性，那么你不需要async。在您的场景中，听起来您可以使用这种方法，这很好。
对于销售的软件，特别是移动应用程序，标准更高。那些会死机的应用已经过时了。移动平台真的不喜欢冻结的应用程序，因为你冻结了整个屏幕而不仅仅是一个窗口——我知道至少有一个平台会执行你的应用程序并断开网络访问，如果它冻结了，它就会自动被应用商店拒绝。冻结在现代应用中是不可接受的。
但就像我说的，对于你的具体情况，你可以不去async。