我一直在一个新的财务分析项目中使用 Rx，该项目异步接收所有数据。我对我的个人生产力以及我的基于事件的代码的可理解程度感到非常惊讶（与以前的事件处理程序模型相反，它具有复杂的嵌套 ifs 和随处可见的随机状态变量。）。有没有其他人有机会玩它，如果有，你有什么想法？
问问题
1972 次
4 回答
11
我相信反应式扩展极大地简化了复杂的事件驱动编程的某些部分，但作为一个整体的问题并没有“解决”。
它确实可以处理许多情况，比以前更干净、更优雅。但是，它并不总是（必然）对某些异步模式的生成有帮助，在这些异步模式中，事件驱动编程仍然很困难。Rx 确实专注于处理事件的订阅端，但不一定是等式的生产端。
对于一些不同的示例，以及对未来版本的 C# 考虑什么来处理一些更复杂的异步模型的想法，我建议观看Luca Bolognese 的 PDC Talk。他提出了语言团队正在研究的一些想法，以帮助异步开发的创作方面，例如IAsync<T>直接生成类似“迭代器”的语法，具有支持事件生成的语言特性。
于 2010-01-16T00:01:28.780 回答
1
在http://channel9.msdn.com/posts/DC2010T0100-Keynote-Rx-curing-your-asynchronous-programming-blues, Bart de Smet 出色地解释了如何将事件流作为一个一流的概念来处理，让您考虑如何实现，例如。Throttle 或 DistinctUntilChanged 每次都必须使用大量容易出错的样板代码。这些运算符以可重用和可组合的方式封装这些行为。所以我的观点是，肯定有进一步发展的空间（参见例如对冷可观察的担忧），但这些工具应该在每个开发人员的工具箱中。通常的控制流结构可能会将其用于单线程执行，但在当今高度并发的分布式世界中，我认为 Observable（甚至更好，EventStream/Property）是一个适当的抽象。
于 2012-05-30T10:18:15.193 回答
1
不。复杂事件驱动编程的问题源于这样一个事实，即任何复杂的事件驱动计算都用动态循环图表示。使用线性编程文本不能方便地表示该图。唯一的出路是拥有多种工具将文本程序表示形式转换为可视图形形式并返回，并动态和静态地检查程序的正确性。
于 2019-03-02T19:19:10.957 回答
0
我刚刚看过一个关于 RX 扩展的网络广播，没有玩过，发现解释太复杂了……我以为创作者是建筑师宇航员。
现在我只是不明白经典事件处理程序的问题在哪里......当我不得不在客户端和服务之间使用异步通信时，我总是找到优雅的解决方案。
但是我很好奇其他人使用这个框架的经验，根据这个线程的答案，我会再试一次。
于 2010-01-16T00:02:20.570 回答