整体架构思路：从时间轴上，web1.0到web2.0，从后端的mvc，到前端的mvc，再到mvp 到 mvvm。
1.web1.0时代
1.1 无架构模式：
很多系统都是基于服务端渲染，所有数据的查询，逻辑处理，展示都是在服务端完成。比如jsp，asp.net,php。 客户端把返回的html,js,css直接展示。
- 缺点：服务端压力大，所有处理都集中在服务端，代码前后端逻辑耦合度太高，不利于维护
- 优点：架构简单易理解，客户端很轻薄，没有过多的处理，利于SEO
1.2 MVC模式（服务端）：
服务端分层架构MVC
- M：Model 数据模型层
- V: View 视图层
- C: Controller控制逻辑层
常见的有SSH ， springMVC ， asp.net mvc
View 主要是使用一些模版语法渲染数据。
当年没有严格的前后端，学习的内容太多以至于各个都不精通，渐渐的分离出，前端，当时的前端只是简单的把设计稿转成html和简单的js交互，俗称：切图仔。
- 优点：分层架构，职责清晰，容易维护
- 缺点：前端页面开发效率不高，前后端职责不清晰
2.web2.0时代
2.1 无架构模式：
自从Gmail的出现，有了ajax技术，前后端职责更清晰，前端可以同ajax请求后台数据，基于接口的数据前端进行动态的更新和交互。
- 优点：前端更加专注于开发页面的实现，数据通过后台接口提供，ajax实现局部刷新，减少了服务器负载的交互和流量消耗，用户体验提升。同时操作前端UI的库也有很多 如JQuery
- 缺点：由于前端页面和业务越来越复杂，应用的规模越来越大。数据和dom的互相操作变得难以维护。
2.2 MVC模式（客户端）：
2.2.1前端MVC
- Model ： 负责保存数据
- Controller: 负责业务逻辑，根据用户行为对model进行改变
- View：负责视图展示，将model数据可视化出来 都是单向流
- view通知controller
- controller改变model
- model通知view更新
缺点：使用起来，一个新改动都需要实现多个层的代码。不便捷，比如：PureMVC。
2.2.1前端MVC-另外一种模式
- 优点：数据流向更加灵活，比如：backbone。
- 缺点：1.由于 view和controller都可以改变model，model不知道是谁改变的，项目变得混乱。2.由于view也可以改变model，所有大量业务都写在了view，弱化了controller。controller变得可有可无。
2.3 MVP模式（客户端）：
- Model ： 负责保存数据
- View：负责视图展示
- Presenter: 中间人，负责model和view之间的数据流动，model和view不直接打交道。
优点：比mvc灵活，view和model关系更加清晰。互相不直接影响。
缺点：所有的model和view都要通过persenter创建大量的接口代码，来处理接受和更新的动作。persenter变得越来越臃肿。维护麻烦。
多出现在安卓原生开发中
2.3 MVVM模式（客户端）：
- Model ： 负责保存数据，应用的所有逻辑也在这里
- View：负责视图展示
- ViewModel: 视图模型层，是一个胶水层，包含dom 监听+ dom操作封装指令，
VM主要就是通过响应式，自动处理了更新View和model层，代替了MVP中 persenter 要做的工作。
优点：减少了大量的dom操作，view和model解耦，减少维护层之间的关系，只需要专注以数据层的逻辑处理。 缺点：由于是框架生成，如果需要做细致的优化和改造，需要了解框架的实现原理。
总结
- 3者都是框架模式
- mvc早期出现在后端开发，如java的ssh，springmvc，前端在早期也有对应的框架如backbone.js 主要是解决view和model解耦问题
- mvp是mvc的进化，解决mvc开发繁琐问题，view和model都通过presenter通讯，但是由于都写在presenter所有会变得臃肿和难以维护
- mvvm，vm就是presenter的进化，自动处理了presenter 原来要编写的大量逻辑，通过响应式+指令方式，自动处理更新view和model的问题。大大提高了开发效率，并且性能表现好。
