Facebook：MVC不适合大规模应用，改用Flux
由 尼克徐 发布于 2014年05月20日 ｜ 更新于 2014年05月26日tinyfool 等1人欣赏。
Facebook软件工程师Jing Chen，说MVC非常适合小型应用，但是当系统中有很多的模型与相应的视图时，其复杂性就迅速扩大，如下图所示：
根据Chen的说法，这样的程序将会非常难以理解和调试，特别是模型与视图间可能存在的双向数据流动，因此提出了以下Flux设计：
Store包含了应用的所有数据，Dispatcher替换了原来的Controller，当Action触发时，决定了Store如何更新。当Store变化后，View同时被更新，还可以生成一个由Dispatcher处理的Action。这确保了数据在系统组件间单向流动。当系统有多个Store和View时，仍可视为只有一个Store和一个View，因为数据只朝一个方向流动，并且不同的Store和View之间不会直接影响彼此。
全文见： http://www.infoq.com/cn/news/2014/05/facebook-mvc-flux
哪位有兴趣讨论一下？
把Action看成Signal, 把Dispatcher看成EventLoop Manager， 这个FLUX就是传统GUI里面成熟了很多年的MV模型, 比如 Qt的MV (http://qt-project.org/doc/qt-4.8/modelview.html)模型就是不带C的。 MVC中的C是个紧耦合点，用的好，搞通用了，开发时就不需要程序员写C的具体实现了，Signal-Slot加Event Loop(Dispatcher)就搞定了，WEB开发这么多年，流行的架构设计其实一直都比较混沌。
原则上，耦合度越高的地方，越简单越好。比如，工厂类。这个Dispatcher就体现了这一点（文中提到，Dispatcher中没有业务逻辑）。
这里面很有意思的还有那个“数据只朝一个地方流动”，一般写程序都是把数据绑定在ui上，互相影响，但随着逻辑的添加和变动，容易使得程序越来越复杂。
强制数据单向流动，此时view的写法就简单太多了，这个view就象是根据数据来显示一个报表或者画图。
当然还要挂一些事件，注册到dispatcher上。但这种随时可调整的注册事件，让model与view之间的藕合度就很低了。
看起来这种结构很清晰，易实现和维护。
9楼 @尼克徐 ojc也reactive了啊，不错， reactive programming和declarative programming结合效果最佳，一般的过程式编程语言想要reactive programming就得上MVVM这样比较啰嗦的“模式”。
不知道是我一直理解的不对还是其它原因，
这哥们真是facebook的吗？
是他自己一直把mvc用错了吧，还自己重新发明了遍mvc并命了个新名。。。
谁说mvc不能实现数据单向移动的。。。谁让他view直接操作m的？谁说应该那样用c的？
难道是我一直在用错误的mvc所以还没出现这哥们的问题？