您可以在百度里搜索“深入浅出React和Redux 艾草文学(www.321553.xyz)”查找最新章节！

　　3.1.1 MVC框架的缺陷

　　MVC框架是业界广泛接受的一种前端应用框架类型，这种框架把应用分为三个部分：

　　·Model（模型）负责管理数据，大部分业务逻辑也应该放在Model中；

　　·View（视图）负责渲染用户界面，应该避免在View中涉及业务逻辑；

　　·Controller（控制器）负责接受用户输入，根据用户输入调用对应的Model部分逻辑，把产生的数据结果交给View部分，让View渲染出必要的输出。

　　MVC框架的几个组成部分和请求的关系可以用图3-1表示。

　　图3-1 MVC框架

　　这样的逻辑划分，实质上与把以一个应用划分为多个组件一样，就是“分而治之”。毫无疑问，相比把业务逻辑和界面渲染逻辑混在一起，MVC框架要先进得多。这种方式得到了广泛认可，连Facebook最初也是用这种框架。

　　但是，Facebook的工程部门逐渐发现，对于非常巨大的代码库和庞大的组织，按照他们的原话说就是“MVC真的很快就变得非常复杂”。每当工程师想要增加一个新的功能时，对代码的修改很容易引入新的bug，因为不同模块之间的依赖关系让系统变得“脆弱而且不可预测”。对于刚刚加入团队的新手，更是举步维艰，因为不知道修改代码会造成什么样的后果。如果要保险，就会发现寸步难移；如果放手去干，有可能引发很多bug。

　　一句话，MVC根本不适合Facebook的需求。

　　为何被业界普遍认可的MVC框架在Facebook眼里却沦落到如此地步呢？

　　图3-2是Facebook描述的MVC框架，在图中，我们可以看到，Model和View之间缠绕着蜘蛛网一样复杂的依赖关系，根据箭头的方向，我们知道有的是Model调用了View，有的是View调用了Model，好乱。

　　这就有意思了，怎么图3-2的画风和通常我们所描述的MVC框架画风很不一样呢？

　　MVC框架提出的数据流很理想，用户请求先到达Controller，由Controller调用Model获得数据，然后把数据交给View，但是，在实际框架实现中，总是允许View和Model可以直接通信，从而出现图3-2的情况。

　　图3-2 MVC的缺点

　　非常遗憾的是，在一些官方的教学文档中，甚至是Android和iOS的教学文档中的例子中，也会出现View和Model直接通信的例子。不过这种状况逐渐在改变，因为越来越多的同行发现，在MVC中让View和Model直接对话就是灾难。

　　当我向以前没接触过Flux的朋友介绍Flux的时候，发现了一个有意思的现象。凡是只在服务器端使用过MVC框架的朋友，就很容易理解和接受Flux。而对于已经有很多浏览器端MVC框架经验的朋友，往往还要费一点劲才能明白MVC和Flux的差异。

　　造成这种认知差别的主要原因，就是服务器端MVC框架往往就是每个请求就只在Controller-Model-View三者之间走一圈，结果就返回给浏览器去渲染或者其他处理了，然后这个请求生命周期的Controller-Model-View就可以回收销毁了，这是一个严格意义的单向数据流；对于浏览器端MVC框架，存在用户的交互处理，界面渲染出来之后，Model和View依然存在于浏览器中，这时候就会诱惑开发者为了简便，让现存的Model和View直接对话。

　　对于MVC框架，为了让数据流可控，Controller应该是中心，当View要传递消息给Model时，应该调用Controller的方法，同样，当Model要更新View时，也应该通过Controller引发新的渲染。

　　当Facebook推出Flux时，招致了很多质疑。很多人都说，Flux只不过是一个对数据流管理更加严格的MVC框架而已。这种说法不完全准确，但是一定意义上也说明了Flux的一个特点：更严格的数据流控制。

　　Facebook已经无心在MVC框架上纠缠，他们用Flux框架来代替原有的MVC框架，他们提出的Flux框架大致结构是图3-3的模样。

　　图3-3 Flux的单向数据流

　　一个Flux应用包含四个部分，我们先粗略了解一下：

　　·Dispatcher，处理动作分发，维持Store之间的依赖关系；

　　·Store，负责存储数据和处理数据相关逻辑；

　　·Action，驱动Dispatcher的JavaScript对象；

　　·View，视图部分，负责显示用户界面。

　　如果非要把Flux和MVC做一个结构对比，那么，Flux的Dispatcher相当于MVC的Controller，Flux的Store相当于MVC的Model，Flux的View当然就对应MVC的View了，至于多出来的这个Action，可以理解为对应给MVC框架的用户请求。

　　在MVC框架中，系统能够提供什么样的服务，通过Controller暴露函数来实现。每增加一个功能，Controller往往就要增加一个函数；在Flux的世界里，新增加功能并不需要Dispatcher增加新的函数，实际上，Dispatcher自始至终只需要暴露一个函数Dispatch，当需要增加新的功能时，要做的是增加一种新的Action类型，Dispatcher的对外接口并不用改变。

　　当需要扩充应用所能处理的“请求”时，MVC方法就需要增加新的Controller，而对于Flux则只是增加新的Action。

　　我们已经基本了解了Flux是怎么一回事，接下来就要实践，看看怎么用Flux改进一下我们的React应用。 深入浅出React和Redux