前言

1，MVC、MVVM、MVP都属于框架模式
- 框架是对软件进行分工，设计模式是对具体问题提出的解决方案，两者有本质的区别
2.MVC模式是面向开发最常用的模式，同时也是最经典的模式
- 其他的模式还有MTV、MVP、CBD、ORM等等很多
3.所有的其他模式MVVM或者MVP都是在MVC的基础上建立的
- MVC模式是任何模式的根源，有万变不离其宗之理
4.一个项目并不是只有一个MVC和一个MVVM，而可能是每一个功能每一个界面都对应了一个MVC
- 所以一个完整的项目是由很多个MVC和MVVM或者MVP组成的
5.目前网络上的水军很多，有很多人混了一年半载开发经验，然后看了一两篇文章就觉得MVC怎么怎么不好，有说MVVM模式多么多么牛逼的，也有说MVP模式多么多么牛逼的
- 其实这也反映了市场上很多人对框架模式的一知半解的态度
  - 笔者认为，任何一款软件都是在面对不同的功能时针对这几种模式之间有一个良好的权衡，而不是一位的偏袒某一种模式

思考题1：应用软件是由什么组成的？

视图和模型之间并不直接进行交互，而是通过控制器（controller）的协调来进行交互
- 这就是MVC模式的组成结构：视图（View）、控制器（Controller）、模型（Model）

实例：当用户点击一个按钮，请求网络数据，然后刷新当前taleview
- 1.首先c层获取用户的点击按钮事件，然后向M层发送指令请求数据
  - 注意：此时M层请求的数据并不是直接丢给界面的tableview，而是将对象的模型M传递给C层
    - M层是通过代理来传递给C层的（网络请求类的代理或者block回调）
- 2.C层获取到M层返回的网络数据之后，直接在C层给V层（tableview）发送刷新的指令reloadData
- 3.当V层（tableview）想要告知C层我已经准备开始刷新了，你给我数据吧，是通过代理和数据源方法来告知的
MVC模式的核心就是定义了视图（view）、控制器（controller），数据（model）之间各行其道不能越界的职责
- 可以联想到交通规则中的实线不能便道，虚线可以变道的规则
MVC模式的优点（由于MVC很好的分离了视图层和业务层，所以它具有以下优点）
- 耦合度低
- 开发速度快
- 可维护性高
MVC模式的缺点
- 由于一味地强调每一个层级之间的严格关系，当MVC三者之间，当C层需要处理的逻辑很多或者V层界面展示非常复杂的时候，就会导致某一个View文件或者Controller文件代码非常的多，甚至有四五千行代码的时候，我们维护起来就非常的麻烦。

此处有笔误，应该是MVVM模式下是将C层拆分成M层和V层，也就是常说的ViewModel
MVVM模式产生的由来就是当MVC模式下的C层代码量很多的时候将其拆分成M层和C层
- 比如说父子控制器可以理解成是MVVM模式
- ViewModel也是一种MVVM模式的体现，ViewModel本身是一个对象，它的内部维护了视图和视图对应的逻辑
MVVM模式的本质就是对MVC模式进行一个拆分，解决了MVC模式下代码臃肿的问题
MVVC模式的优点
- 可复用性比MVC模式高（拆分的V和M可以被其他的mvc或者mvvm复用）
- 耦合度低
MVVM模式缺点
- 项目文件增多

MVP模式的定义
- 作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。
  - *也就是说，如果MVC模式中V不能直接访问M，就和MVP无异
关于MVP模式误区的解读
- MVP模式主要是解决MVC模式下V可以直接访问M导致耦合度很高的问题，但是根据网易公开课斯坦福大学教授的说法，MVC模式中V和M本来就是不能够进行交互的
  - 所以MVP模式的诞生个人认为是一个笑话，是对MVC模式理解的不够深刻所导致的
以下是网易公开课斯坦福大学教授Paul Hegarty（世界知名级教授）讲解MVC模式的示意图

所有的MVC或者MVVM模式的目的都是为了代码的解耦和易读性，MVC之间的沟通本质上还是OC的对象间消息机制的使用，以下是oc中的三种消息机制
- 代理
- 通知
- kvo
什么时候使用MVC，什么时候使用MVVM，这主要是由具体的业务需求所决定的
- 业务需求很简单，控制器代码量不复杂（低于两千行代码），优先考虑MVC
- 业务需求比较复杂，控制器代码量很多（高于两千行）或者V和M的复用性极高，可以考虑MVVM