“Yeah It’s on. ”
背景
今天参与面试了一个前端，问到了项目中使用的架构，面试人员说用的是mvvm,但是说的的很含糊，可能虽然是项目开发人员，但是参与设计架构比较少，对架构也没有太多深入了解。 基于我在以往项目中对架构的了解，梳理一下，进入正题。
MVC
MVC架构，对于程序员来说特别常见，我最开始学习写代码的时候第一个了解的架构。
- Model：数据及业务模型，负责处理和存取数据。
- View：界面，负责显示数据和与用户交互。
- Controller：处理中心，用来管理Model和View, Model和View都是控制器里的对象，主要负责将数据模型展示在视图上，同时也可负责界面交互的处理。
- Model和View是不相通的，所有的事情只能通过控制器进行交换。
- 这种架构的优点在我看来，阅读代码简单，不管小白还是大牛写起来都能写。但是缺点也很明显，由于优点是谁来都能快速上手，每个开发人员代码水平参差不齐，导致代码里面各种代码风格，各种耦合无法避免，导致vc臃肿不堪。
- 另外好多人提到MVC就说耦合和臃肿，我持不同意见，我认为只要有良好的类的封装和规范的调用，会比其他框架开发效率和调试效率更高。
MVVM
- 再说MVVM架构，这种架构是MVC的非直接变形的App设计模式。与MVC相比其实并没啥特别大的不同，所使用的机制也都差不多，最大的区别在于ViewModel对响应式编程的使用。
- 视图通过 ViewModel来渲染，并且把交互状态提交给 ViewModel
- Model通过ViewModel来交付
- Model本身的get\set 同步给ViewModel
- ViewModel是一个控制器的管理者，遵循协议去驱动其他类
- 优点是这种架构设计不会使代码强耦合和VC臃肿，由于多了一层ViewModel桥接,导致Block多，需要注意循环引用问题而且可读性和调试问题的成本相较于MVC会更高。
MVP
- MVP是介于MVC和MVVM两者间的实现，使用单独的presenter对象去处理业务逻辑和View交互。
- MVP架构是通过presenter基于代理驱动的，Controller可以理解为初始化配置的工具类。
- view的数据渲染交给了适配器，preseter自会驱动适配器
- 按照MVP的架构思想，需要按照相应的格式规则去操作各类代码，作为开发者可以规范化协作的代码。
但是不管是什么架构，架构都是服务于项目开发人员的，所有人员共同遵循一个合同，都很好的履行协议，才可以使开发效率最大化。 架构没有谁比谁好，谁比谁差，只有最适合开发人员和项目的架构。
结束
欢迎交流。
—— Ade