MVC/MVVM（Redux的核心概念）
Redux核心概念
action reducer store
MVC/MVVM
MVC/MVVM都是一个UI的解决方案，是一种软件架构方式，用于降低UI，以及UI关联的数据的复杂度。
传统的服务器端的MVC
环境：
- 服务端需要响应一个完整的HTML
- 该HTML中包含页面需要的数据
- 浏览器仅承担渲染页面的作用
以上的这种方式叫做服务端渲染，即服务器端将完整的页面组装好之后，一起发送给客户端。
服务器端需要处理UI中要用到的数据，并且要将数据嵌入到页面中，最终生成一个完整的HTML页面响应。
为了降低处理这个过程的复杂度，出现了MVC模式。
Controller: 处理请求，组装这次请求需要的数据 Model：需要用于UI渲染的数据模型 View：视图，用于将模型组装到界面中
前端MVC模式的困难
React解决了 数据 -> 视图 的问题
- 前端的controller要比服务器复杂很多，因为前端中的controller处理的是用户的操作，而用户的操作场景是复杂的。
- 对于那些组件化的框架（比如vue、react），它们使用的是单向数据流。若需要共享数据，则必须将数据提升到顶层组件，然后数据再一层一层传递，极其繁琐。 虽然可以使用上下文来提供共享数据，但对数据的操作难以监控，容易导致调试错误的困难，以及数据还原的困难。并且，若开发一个大中型项目，共享的数据很多，会导致上下文中的数据变得非常复杂。
比如，上下文中有如下格式的数据：
value = {
users:[{
},{
},{
}],
addUser: function(u){
},
deleteUser: function(u){
},
updateUser: function(u){
}
}
MVVM
-
View层：视图展示。包含UIView以及UIViewController，View层是可以持有ViewModel的。 ViewModel层：视图适配器。暴露属性与View元素显示内容或者元素状态一一对应。ViewModel 只关心数据和业务的处理（数据到页面的处理和页面的通知），不关心 View 如何处理数据。以 Vue 框架来举例，ViewModel 就是组件的实例。 Model层：数据模型与持久化抽象模型。数据模型很好理解，就是从服务器拉回来的JSON数据。而持久化抽象模型暂时放在Model层，是因为MVVM诞生之初就没有对这块进行很细致的描述。按照经验，我们通常把数据库、文件操作封装成Model，并对外提供操作接口。（有些公司把数据存取操作单拎出来一层，称之为DataAdapter层，所以在业内会有很多MVVM的变种，但其本质上都是MVVM）。 Binder：MVVM的灵魂。可惜在MVVM这几个英文单词中并没有它的一席之地，它的最主要作用是在View和ViewModel之间做了双向数据绑定。如果MVVM没有Binder，那么它与MVC的差异不是很大。
前端需要一个独立的数据解决方案
Flux
Facebook提出的数据解决方案，它的最大历史意义，在于它引入了action的概念
action是一个普通的对象，用于描述要干什么。action是触发数据变化的唯一原因
store表示数据仓库，用于存储共享数据。还可以根据不同的action更改仓库中的数据
示例：
var loginAction = {
type: "login",
payload: {
loginId:"admin",
loginPwd:"123123"
}
}
var deleteAction = {
type: "delete",
payload: 1 // 用户id为1
}
Redux
在Flux基础上，引入了reducer的概念
reducer：处理器，用于根据action来处理数据，处理后的数据会被仓库重新保存。
