我已经阅读了一些 Microsoft 团队或其他作者的大量技术文档，详细介绍了新的 TPL 数据流库、异步/等待并发框架和 TPL 的功能。但是，我还没有真正遇到任何明确描述何时使用的内容。我知道每个都有自己的位置和适用性，但我特别想知道以下情况：
我有一个完全在进程中运行的数据流模型。顶部是一个数据生成组件 (A)，它生成数据并通过数据流块链接或通过引发事件将其传递给处理组件 (B)。(B) 中的某些部分必须同步运行，而 (A) 大量受益于并行性，因为大多数进程都受 I/O 或 CPU 限制（从磁盘读取二进制数据，然后对其进行反序列化和排序）。最后，处理组件 (B) 将转换后的结果传递给 (C) 以供进一步使用。
我特别想知道何时在以下方面使用任务、异步/等待和 TPL 数据流块：
启动数据生成组件 (A)。我显然不想锁定 gui/仪表板，因此这个过程必须在不同的线程/任务上运行。
如何调用（A）、（B）、（C）中不直接参与数据生成和处理过程但执行可能需要数百毫秒/秒才能返回的配置工作的方法。我的直觉是，这就是 async/await 的亮点？
我最挣扎的是如何最好地设计从一个组件传递到下一个组件的消息。TPL 数据流看起来很有趣，但有时对我的目的来说太慢了。（注意最后关于性能问题）。如果不使用 TPL Dataflow，我如何通过进程间任务/并发数据传递来实现响应性和并发性？例如，如果我在任务中引发事件，订阅的事件处理程序会在同一个任务中运行，而不是传递给另一个任务，对吗？综上所述，组件（A）在将数据传递给组件（B）而组件（B）检索数据并专注于处理数据后如何开展业务？这里最好使用哪种并发模型？我在这里实现了数据流块，但这真的是最好的方法吗？
我想以上几点总结表明我在如何使用标准实践设计和实现 API 类型组件方面遇到了困难？方法是否应该设计为异步的，数据输入作为数据流块，数据输出作为数据流块或事件？一般来说，最好的方法是什么？我之所以问，是因为上面提到的大多数组件都应该独立工作，因此它们基本上可以在内部被换出或独立更改，而无需重新编写访问器和输出。
性能注意事项：我提到 TPL 数据流块有时很慢。我处理高吞吐量、低延迟类型的应用程序和目标磁盘 I/O 限制，因此 tpl 数据流块的执行速度通常比同步处理单元慢得多。问题是我不知道如何将流程嵌入到它自己的任务或并发模型中以实现与 tpl 数据流块已经处理的类似的东西，但没有 tpl df 带来的开销。