前后端分离的架构演变——MVC、MVP和MVVM
前后端分离之前的架构存在一定的问题–前端缺乏一种可行的开发模式。整体的内容都杂糅在一起，一旦应用增大，就会导致难以维护。因此前后端分离式大型应用程序的必选架构。出现前后端分离的架构之后，前端开发业务逐渐增多，责任也更加巨大，开发者急需一种较好的框架来规范整个应用。因此，前段MVC随之而来。
MVC
前端MVC应该与后端类似，具备view,Controller和Model。
- Model：负责保存应用数据，与后端数据进行同步。
- Controller：负责业务逻辑，根据用户行为对Model数据进行修改。
- View：负责视图展示，将model中的数据可视化出来。
理论模型如下：
这样的模型，理论上是可行的，但在实际开发中，并不会这样去操作。因为开发过程需要灵活，而这种模式不满足灵活的条件。例如，一个小小的事件操作，都必须经过这样的一个流程，那么开发就不那么便捷了。
在实际场景中，往往会看到另一种模式，如下图：
这种模式在开发中更加灵活，backbone.js框架就是这种模式。但是这种灵活会导致一些严重的问题（详情戳原文）：
- 数据流混乱。
- View比较庞大，controller比较单薄。
MVP
MVP与MVC很接近，P指的是Presenter，presenter可以理解为一个中间人，它负责着view与model之间的数据流动，防止view与model直接交流。图示如下：
我们可以看到，presenter负责和model进行双向交互，还和view进行双向交互。这种交互方式，相对于MVC来说少了一些灵活，View变成了被动视图，并且本身变得很小。他虽然分离了View和Model，但是应用逐渐变大之后，缺陷也会随之暴露：由于大部分逻辑都需要presenter去进行管理，从而导致presenter体积增大，难以维护，如果需要去解决这个问题，或许可以从MVVM的思想中找到答案。
MVVM
所谓MVVM，可以分解为Model - View - ViewModel。ViewModel可以理解为在presenter基础上的进阶版。图示如下：
在这里View是ViewModel的外在显示，和ViewModel的数据是同步的，一旦View中数据发生变化，会自动同步到ViewModel。然后ViewModel可以将变化的数据传给Model；反过来也一样，Model中的数据一旦发生改变，就会将值传给ViewModel，而ViewModel会同步更新到View中，现在的框架实现这样的形式，各有各的不同。主要的框架Angular2，Vue都是实现了这样子的模式。
这种的好处就是View和Model之间被分离开来。View不知道Model的存在。这是一个非常松耦合的设计。
Flux或者Redux
讨论完上面的三种框架，我们再来看一下Flux。之前，我们在讨论MVC的时候，提及过MVC最主要的缺点就是数据流混乱，难以管理。但是，Facebook却在这个基础上对MVC做出了改变，那就是——单向数据流。只要将数据流进行规范，那么原来的模式还是大有可为的。
我们可以来看一下，Flux框架的图示：
从图中，我们可以看到形成了一条Action到Dispatcher，再到Store，之后是View的，一条单向数据流。在这里Dispatcher会严格限行我们操作数据的行为，而Store也不会暴露setter接口，让其随意被修改。最终，这样的一套框架在大多数场景下，比MVC更加完美。