Flux vs MVC设计模式
在Web应用程序开发中，MVC也是客户端和服务器端应用程序的设计模式，而Flux是Facebook提出的一种新的应用程序体系结构，它与MVC相同，但侧重于单向数据流。哪种应用更好？让我们做一个比较：Flux与MVC。
MVC 是 Model View Controller
MVC架构
在MVC设计中，最好将每一层分开，例如视图，模型，控制器。尽管它们中的许多都修改了实际的原理，但有些人提出了MVVM和MV *类型的体系结构，但重点是MVC，这就是为什么它是一个最成功的架构。
- 模型：管理应用程序域的行为和数据
- 视图：表示模型在UI中的显示
- 控制器：接受用户输入，操纵模型并导致视图更新
MVC的优点：
极大地分离了代码，很好地实现了MVC
- 将表示形式与模型分开应该可以提高可测试性。
- 将视图与控制器分离，这在Web界面中最有用。
MVC中的缺点：
在服务器端，MVC是好的，但是在客户端，大多数JS框架都提供了数据绑定支持，该视图可以使视图直接与模型进行通信，但事实并非如此，由于存在一定的适用范围，因此很多时候调试起来很困难通过多种方式更改的属性。
MVC调试问题
Facebook开发人员在扩展其MVC应用程序时遇到问题，结果世界获得了新的体系结构flux。在FB开发人员会议上，他们展示了如何使用上图来遵循MVC来弄乱事情。
Facebook在开发聊天系统时遇到了问题，view1操作model1，model1更新view2，就像他们的系统具有循环依赖关系一样，这就是为什么他们想出解决方案的原因。
Flux
Flux是Facebook用于构建客户端Web应用程序的应用程序体系结构。它通过利用单向数据流来补充React的可组合视图组件。它更像是一种模式，而不是正式的框架，您无需大量新代码即可立即开始使用Flux。
-
Actions是具有类型属性和一些数据的简单对象。例如，一个动作可以是{“ type”：“ IncreaseCount”，“ local_data”：{“ delta”：1}} -
Stores包含应用程序的状态和逻辑。最好的抽象方法是将商店视为管理应用程序的特定域。它们与MVC中的模型不同，因为模型通常会尝试为单个对象建模，而Flux中的存储可以存储任何内容 -
Dispatcher充当中央枢纽。调度程序处理操作（例如，用户交互）并调用商店已向其注册的回调。调度程序与MVC模式中的控制器不同–通常，调度程序内部没有太多逻辑，您可以在项目中重复使用同一调度程序 -
Views是控制器视图，在大多数GUI MVC模式中也很常见。他们聆听Stores的变化，然后适当地重新渲染自己。view还可以向调度程序添加新操作，例如，在用户交互方面。视图通常在React中编码，但是没有必要将React与Flux一起使用
Flux体系结构
Flux是在MVC模式中进行一些修改的方法，因此可以理解MVC和Flux。
真正的MVC是否不可扩展？
我们将发现有一个具有多个模型的控制器。这不是MVC负责人讲话的方式。在MVC中，一个控制器只有一个模型，因此从Facebook实现中，他们只有多个控制器可以操纵模型，因此MVC Design没错。
什么是事件驱动方法？
在MVC树结构中，将视图作为叶子，将控制器作为父视图，一个视图可能具有多个父视图，因此兄弟姐妹之间很难进行通信，直到并且除非您在通信中涉及到公共父视图为止。
因此，如果在应用程序中需要与并行元素进行通信，则事件驱动的体系结构更适合。
与MVC相比，我们应该更喜欢FLUX吗？
我认为Flux并不是另一种体系结构，而是MVC本身。到目前为止，我们未能在客户端应用程序中正确实现MVC。Flux向我们展示了实施MVC的正确方法。将控制器重命名为调度员并创建商店而不是模型并不能使您成为一个全新的体系结构。而是一种更好的结构。因此，是的，与客户端中现有的MVC相比，Flux是更好的方法。
基于Flux的JS framworks实现：
您可以探索各种基于Flux架构的JavaScript实现，并根据自己的需求决定使用合适的实现。
结论：
到目前为止，我们已经讨论了MVC和Flux，我们可以确定MVC设计没有错，但是在客户端实现MVC不会造成冲突，并且Flux也类似于MVC，但是与MVC相比，flux的实现方式很好。
那么选择哪一个呢？
它基于要开发的应用程序类型以及首选的方法类型？事件驱动或数据绑定，所以如果您要处理复杂的数据模型，最好使用Flux！否则您会喜欢数据绑定和MVC。
显然，绝对不需要更改或重新架构任何现有的基于MVC的应用程序。
