考虑一个基本的WPF业务线应用程序，其中服务器和客户端都在本地网络上运行。服务器只是公开客户端（在台式计算机上运行）调用的Web API。 UI将包含CRUD样式的屏幕，其中的按钮用于触发对服务器的调用。
在我的应用程序的原始版本中，这些UI操作都不是异步的;用户界面将在通话期间冻结。但没有人抱怨用户界面没有反应，也没有人注意到;通话时间通常不到四分之一秒。在极少数情况下，如果网络连接断开，只要操作超时，UI就会冻结，这是眉毛被抬起的唯一时间。
既然我已经开始为所有服务器调用实现async / await，很快就会发现我手上有一个新问题：处理重入和取消的复杂性。从理论上讲，现在用户可以在呼叫正在进行时点击任何按钮。他们可以启动与待处理的操作冲突的操作。他们可能会无意中创建无效的应用程序状态。他们可以导航到不同的屏幕或注销。现在，必须考虑所有这些以前不可能的情况。
好像我打开了潘多拉盒子。
我将此与我的旧的非异步设计形成对比，在设计服务器调用期间，用户界面会锁定，用户只需不点击任何内容。这保证了它们不会污染任何东西，因此允许应用程序代码保持至少10倍更简单。 那么所有这些异步的现代方法真正获得了什么？我敢打赌，如果用户并排比较同步和异步版本，他们甚至不会注意到异步版本的任何好处;呼叫非常快，繁忙的指示器甚至没有时间渲染。 它似乎只是一大堆额外的工作，复杂性，难以维护的代码，几乎没有什么好处。我听到KISS原则叫......
那我错过了什么？在LOB应用程序场景中，异步的好处是保证额外的工作吗？
答案 0 :(得分：3)
那么所有这些异步的现代方法真正获得了什么呢？
您已经知道答案：async对UI应用的主要好处是响应能力。 （async在服务器端的主要好处是可伸缩性，但这不会在这里发挥作用。）
如果您不需要响应，那么您不需要async。在你的场景中，听起来你可能会采用这种方法，这没关系。
对于出售的软件 - 特别是移动应用程序 - 标准更高。冻结的应用程序是如此'90年代。移动平台真的不喜欢冻结的应用程序，因为你冻结了整个屏幕而不仅仅是一个窗口 - 我知道的至少一个平台会执行你的应用程序并放弃网络访问，如果它冻结了，它会自动从应用商店中拒绝。对于现代应用来说，冻结是不可接受的。
但就像我说的那样，对于你的特定情况，你可能会离开async。