在GitHub上可访问Flux TodoMVC教程及其源代码。
Facebook可以使用任何他们觉得合适的设计，但这个问题依旧存在。MVC适合大规模应用吗？毕竟，有那么多大规模网站。
更新 原文在英文站发布后，许多开发者在Reddit上评论Facebook的MVC。以下是一些评论，有些认为Facebook误用了MVC，而另一些则认为他们做了正确的事：
giveupitscrazy： 这毫无意义。 其一，他们的MVC图形绝对是错的。他们描绘了一个单一控制器处理多个模型，你几乎可以肯定会基于它们交互的Model或者逻辑分区来分离控制器。 很显然，他们所描述的这样一个程序无法工作，同时它也不是真正的MVC。 如果你比较他们的Flux图形和真正的MVC图形，你就会得出清晰的结论，对Web应用来说MVC没有任何内在问题。 balefrost： 并且⋯⋯事情是这样的⋯⋯他们的Flux图与你的MVC图非常接近。 他们重新发明了真正的MVC，然后决定给它一个新名字。哈哈！ hackinthebochs： 看起来这个架构将MVC变成了某种基于事件的东西。“Store”将它们自己注册到Dispatcher（可能是任何调用依赖关系），Dispatcher处理Action并确保正确的调用链。这样就将保证正确调用顺序的压力从Controller转移到Dispatcher和Store。这将减少改变行为所需的理解。 runvnc： 我刚扫了一眼，虽然我不认为自己对这个非常理解，但我理解和同意它的总体思路。
Reddit用户jingc09，通过她的评论，好像是Jing Chen，增加了一些回复： jingc09：是啊，这是个复杂的幻灯片（那张有多个模型和视图并且双向数据流的片子），部分原因是因为MVC究竟是什么没有统一的认识，很多人对它有不同的观点。我们真正想讨论的是双向数据流，数据变化能向后循环并产生级联效应。
她还试图澄清Flux的Dispatcher不是MVC Controller： 我想澄清的一件事是，Dispatcher没有扮演Controller同样的角色。Dispatcher中没有业务逻辑，我们在多个应用中使用相同的Dispatcher代码。它只是一个中心枢纽，将事件分发给感兴趣的订阅者（通常是Store）。但在Flux中它是很重要的，因为它强制单向数据流⋯⋯
Wikipedia关于MVC Controller解释： Controller能发送命令到Model去更新Model的状态（例如编辑文档）。它也能发送命令到相关的View去修改这个Model的View的展现（例如滚动文档）。
对此，Chen评论道： Dispatcher不能做任何这些事，命令必须从其它地方（View、服务器响应和实时更新）传递到Dispatcher。https://github.com/facebook/react/blob/master/examples/todomvc-flux/js/dispatcher/Dispatcher.js 也许有助于说明这一点。
根据Reddit上的这些评论，关于MVC是什么以及应该如何实现，似乎有些混乱。
考虑到Facebook对MVC的处理，我们有两个观察：
1）第一张幻灯片似乎真的画了太多的Model和View，让人怀疑现实生活中真的有类似的情况吗？Facebook使用Flux解决的问题是一个有3个View的聊天应用。 2）在他们的MVC例子中，为何是View产生数据流，从而造成双向流动？同时，在Flux图中，为何是View产生Action？View不应该产生任何东西。View只是“视图”，没有别的。Facebook是在误用MVC吗？
原文链接：Facebook: MVC Does Not Scale, Use Flux Instead 转自 http://www.infoq.com/cn/news/2014/05/facebook-mvc-flux?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global | 
