RX扩展“解决”了复杂事件驱动编程的问题了吗?

我相信反应式扩展显著地简化了复杂的、事件驱动的编程的某些部分,但问题整体上并没有“解决”。

它确实能处理许多情况,比以前可能的更干净、更优雅的方式。然而,在某些异步模式的生成方面,它(必然)并不总是有帮助,因为在这些异步模式中,事件驱动的编程仍然很困难。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很好地解释了如何将事件流作为一个一流的概念来处理,通过让您思考如何实现(例如,节流阀或每次强制执行大量容易出错的样板代码)来提高抽象级别。这些运算符以可重用和可组合的方式封装这些行为。所以我的观点是,确实存在进一步发展的空间(例如,对冷观测的关注),但是这些工具应该放在每个开发人员的工具箱中。通常的控制流构造可能会将其切割为单线程执行,但在当今高度并发、分布式的世界中,我认为Observable(甚至更好的是,eventstream/property)是一个适当的抽象。

我刚刚看到一个关于RX扩展的网络广播,没有玩过,并且发现解释太复杂…我以为创造者是建筑师宇航员。

现在我不知道经典事件处理程序的问题在哪里…当我不得不在客户机和服务之间使用异步通信时,我总是找到一个优雅的解决方案。

然而,我对其他人使用这个框架的经验感到好奇,根据这个线程的答案,我将再试一次。

不,复杂事件驱动的编程问题源于任何复杂事件驱动的计算都用动态循环图表示。使用线性编程文本无法方便地表示该图。 唯一的出路是拥有多个工具来将文本程序表示转换为可视图形形式并返回,并动态和静态地检查程序的正确性。