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