c# - 我应该为我的 GUI 应用程序使用异步 "all the way"吗？

Question

我通过开发一个相当大的 WPF 应用程序，将通过串行通信控制复杂的硬件，取得了实质性进展。在应用程序“堆栈”的最底部，我有一个串行通信层(利用 .Net“SerialPort”类)。读取和写入硬件设备是系统的基本部分，被业务逻辑层的许多不同领域使用，经常穿插复杂的科学计算和其他此类逻辑；这些 BLL 方法依次从整个 UI 层调用。

目前，业务逻辑层的一切，包括SerialPort读写，都是同步。我唯一一次使用 async/await 是在 UI 层，通常是在调用业务逻辑时。在这里，我将调用包装在 Task.Run() 中，例如:-

private async void SomeButtonClick(object sender, EventArgs e)
{
    await Task.Run(() => _someBLLService.TurnPumpOn());
}

这是一个只需几毫秒的简单示例。一个更复杂的例子是启动一个长时间运行的进程(再次使用上述技术)；该业务逻辑“服务”将运行几秒或几分钟，从硬件收集数据并在此期间执行其他“控制”功能。它会定期将数据广播回 UI 以在图表上绘制(通过 pubsub 事件聚合器框架)。上述技术运行良好，允许 UI 在此类业务层流程发生时保持响应。

我最近一直在考虑“一路异步”，从串行通信代码开始(例如使用 .ReadAsync)，但这会对整个系统产生影响。数十个(如果不是数百个)业务逻辑方法需要重构为异步方法，一直到 UI 层。在这里我可以稍微简化上面的代码:

private async void SomeButtonClick(object sender, EventArgs e)
{
    await _someBLLService.TurnPumpOn();
}

虽然我不反对处理大型重构工作，但我想知道真正的好处是什么。许多人(如 Stephen Cleary)提倡“始终异步”解决方案，但主要目标似乎是在调用长时间运行的 BLL 进程时保持 UI 响应，我的 Task.Run() 技术已经做到了。

Answer 1

由于您的应用(大概)没有承受高负载并且是一个 GUI 应用，使用 async 和 await 的唯一原因是提高工作效率。吞吐量和可扩展性不重要。

因此，做对您来说最方便的事情。这很可能就是您在示例代码中使用的 await Task.Run 模式。

but this would have repercussions across the system

是的。异步具有明显的生产力成本并且具有传染性。只有当你能清楚地表达你从那个选择中获得的好处时才这样做。在这里，唯一的好处是您的 UI 代码短了几个字符。这是您的两个代码片段之间的区别。整个系统的其余部分变得更糟。

也许您一直在关注 C# 社区并顺应潮流一路走向异步。程序员很容易在不理解的情况下跳到神奇的解决方案。许多异步的拥护者甚至无法阐明他们从中获得的具体好处。也有很多团体的想法。不要仅根据互联网建议做出决定。考虑到这一点并自己检查什么是有意义的。