这些指的是框架模式，框架模式不是一门写代码的学问，而是一门管理与组织代码的学问。其本质是一种软件开发的模型。
与设计模式不同，设计模式是在解决一类问题时总结抽象出的公共方法(工厂模式，适配器模式，单例模式，观察者模式 等)，他们与某种具体的技术栈无关，一种框架模式往往使用了多种设计模式，切不要把他们的关系搞混。
mvc：(模型，视图，控制器)
它是一种映射程序，用户通过操作图像上的按钮，来达到操作数据的目的，数据被用户改变后，肯定需要从新生成映射。
1.View: 放置视图相关的代码，原则上里面不应该有任何业务逻辑。
2.Controller: 放置一些绑定逻辑，完成视图与模型之间的映射，原则上这里应该很薄，他只是一个桥梁。
3.Modle: 接收view的注册，当自身数据变化时，执行view的数显函数，主要实现逻辑的地方。
v改变通知c，c交给m处理，m处理完直接通知v。
缺点：
View 和 Model 并不是完全脱离的，还是有一些逻辑耦合
代码量膨胀。
不方便进行更精细的颗粒化控制。(因为view只知道 model被改了，但不知道谁改的!)
model在对应多个view的时候，很难都伺候到位。
mvp：(模型，视图，派发器)
针对mvc的一些问题，在mvp模式下， 斩断了 view 与 model的关系， 当m 改变时，m 通知 p 去改变v， 所以v变得更纯洁(刷新逻辑被移动到了p层，m更加纯粹的只处理业务逻辑)， 为了保证m可以最大程度的复用 ，一部分业务逻辑也从 m 转移到了p所以 mvp下 p 非常厚实。
最后改变v的是在 v与p 之间的一个接口，解决怎么转换以及传值的问题。
m-v-vm
使用 数据绑定(Data Binding)、依赖属性(Dependency Property)、命令(Command)、路由事件(Routed Event) 来搞定与view层的交互
服务器端路由是处理请求 URL 到负责生成相关的 HTML 的代码之间映射的过程。
ViewModel从Model中抽象而来，更贴近于业务模型， 比如你Model中某字段是 true false， ViewModel中可能就是 "黑"，"白"等 这种更贴近业务场景的描述。 ViewModel中的属性直接与某具体控件的属性相绑定。 也就是说当某具体控件发生变化，ViewModel中的 某个字段就会跟着变化，然后Model中的字段也会进一步变化。数据驱动视图
以上述为例:
用户使用UI修改了性别字段:
1.操作触发绑定在UI上的事件(Data Binding 自动完成)
2.事件进入vm层，根据绑定规则，找出对应的vm字段， (如表示性别的组件绑定的是vm中的sex字段)
3.vm上的sex被设置成true，(view层上值为"男" "女"，但是在抽象的vm层中我们用 bool 来表示这个字段)
4.同理寻找m层上的对应字段，m上的sex被vm修改成1
5.m找到所有与sex字段有绑定关系的vm通知他们更新。
6.所有接到通知的vm更新sex字段。
7.vm寻找所有与sex字段有绑定关系的view层控件，通知他们更新(Data Binding 自动完成)。
8.view被更新。所有涉及到sex字段的组件都被刷新。
有时候这个流程未必是从 1 步开始，如果直接对 m 进行修改，则就是从第 4 步开始的。
同理如果没有view层，则没有必要进行 7 ， 8步骤。
这就是说 mvvm 下可以完全干掉 view 层， 方便的进行自动化测试。
不管是 mvc 还是 mvp 或 mvvm ，他们都是 数据驱动 的。核心上基于 m 推送消息，v或p来订阅 这个模型。使用者需要维护的不再是 UI 树，而是抽象的数据。(通过数据，可以随时构建出新的 UI 树)， 当 UI 的状态一旦多起来，这种框架模式的优势便体现出来了。 因为维护数据可比维护 UI 状态爽多了。
Web 应用框架，或者简单的说是"Web 框架"，是建立 web 应用的一种方式。 web 框架技术，例如 Flask 或这 Django 之类的。
前端中的mvc
并不是说 m v c 三者一定要独立出现才行，比如 Backbone。js 它的 controller 层只是一个 router。 其实在传统 mvc 中 controller 里本来就没有太多的逻辑，他只是 一个事件的"传递者"， 加之 javascript 中人们习惯使用匿名函数当事件回调，这样就等于直接在 view 层中把功能函数实现了。 所以 view 与 controller 合并 或者 controller 与model 合并都有可能。
前后端一体式：
前后端分离方案：方案根本要解决的问题是把数据和页面剥离开来。
前端接触的到角色会比后端更多（多数应用型项目/产品，并非所有情况）。
前端开发人员会受到项目/产品经理或客户的直接影响：这个地方应该放个按钮，那个操作应该这么进行……；
前端还要与美工对接——这样的设计不好实现，是否可以改成那样？客户要求必须这么操作，但是这个设计做不到；
前端还要跟后端对接，对于某些应用，甚至是多个后端
换句话说，前端可以成为项目沟通的中心，所以比后端更合适承担主导的角色。
常见请求参数的数据形式有如下一些：
键值对，用于 URL 中的 QueryString 或者 POST 等方法的 Payload
XML/JSON/…，通常用于 POST 等方法的 Payload，也可以使用 multipart 传递
ROUTE，由后端路由解析 URL 取得，在 RESTful 中常用
服务器响应的数据，通常一个完整的响应至少需要包含状态码、消息、数据三个部分的内容，其中
状态码，HTTP 状态码或响应数据中特定的状态属性
消息，通常是放在响应内容中，作为数据的一部分
数据，根据接口协议，可能是各种格式，当前最流行的是 JSON
我们在实践中使用 JSON 形式：还有其它的返回风格设计
{
"code": "number",
"message": "string",
"data": "any"
}
测试：
前后分离之后，前端的测试将以用户体验测试和集成测试为主，而后端则主要是进行单元测试和 Web API 接口测试。如果前后端都要做数据有效性验证，那一定要严格按照文档来进行
要求：接口不只存在于人的记忆中，更要文档化、持久化