iOS基础 - 架构/设计模式：MVC

▶ 什么是 MVC

M - Model 模型：是处理应用程序数据逻辑的部分

V - View 视图：是在应用程序中处理数据显示的部分，视图的创建通常是依据模型数据

C - Controller 控制器：在是应用程序中处理用户交互的部分，通常负责从视图读取数据，控制用户输入，并向模型发送数据，目的是解除数据和视图之间的耦合

▶ MVC 层次结构

1 - 使用 MVC 的目的就是实现 M 和 V 代码的分离，这个模式认为，程序不论简单或复杂，从结构上看，都可以分成三层

① 最上面的一层，是直接面向最终用户的视图层，它是提供给用户的操作界面，是程序的外壳

② 最底下的一层，是核心的数据层，也就是程序需要操作的数据或信息

③ 中间的一层，就是控制层。它负责根据用户从视图层输入的指令，选取数据层中的数据，然后对其进行相应的操作，产生最终结果

注：对于 MVC 你说它是一种架构模式还是一种设计模式 ？其实在计算机开发中的概念定义并非确切明朗，我们只知道它是一种思想即可。这里把它归结为架构模式

▶ MVC 之间通信

1 - Controller -> View：C 层直接控制 V 层，在 C 层里创建 outlet 通讯属性，通过 outlet 对应到 V 层中的控件，直接操作 V 层

2- View -> Controller：

① 通过 target action 这个结构来通讯：C 层自己画个 target ，然后把 action 交给 V 层；当 V 层按钮被按下，就会把 action 发送到 target，这时候 C 层就收到了信息

② 通过代理：如  V 层要告诉 C 层发生什么事情，比如视图将要发生什么事情、询问是否允许等等，就用到了 will、did、should... 这就需要 C 层把自己设置成委托以回应 V 层的 will、did、should...

③ 通过设置 dataSource：如  UITableView 的 dataSource

3 - Controller -> Model：C 层向 M 层提出需求，直接使用 M 层中的数据

4 - Model -> Controller：M 层不能主动勾搭 C 层，如果 M 层数据有了变化，怎么让 C 层知道呢 ？使用 Notification、KVO 机制

5 - Model - View：建议之间永远不要进行通讯，默认两者禁止通讯！M 层和 V 层并没有实质性的关系，一旦关联后当 M 层发生改变，V 层就不得不重写

▶ MVC 缺点/优点

1 - 坏处

① 增加了系统结构和实现的复杂性。对于简单的界面，严格遵循 MVC，可能使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率

② 视图与控制器间的过于紧密的连接：视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了它们的独立重用

③ 视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能

④ 目前一般高级的界面工具或构造器不支持 MVC 架构，改造这些工具以适应 MVC 需要和建立分离的部件的代价是很高的，从而造成使用 MVC 的困难

2 - 好处

① 有利于通过工程化、工具化产生管理程序代码

② 低耦合性，重用性高

③ 可维护性好

▶ 苹果的 MVC

1 - iOS 严格遵循 MVC 设计模式！好处是 M 层和 V 层之间彼此独立，互不影响，两者可以重复利用；坏处是 C 层代码过于臃肿

2 - 其实 M 层和 V 层之间并不是绝对禁止通讯。在实际开发中，两者之间的交互往往能起到意想不到的效果

① 好处是可帮 C 层瘦身，同时将 V 层内部实现的具体细节隐藏起来

② 坏处就是 V 层会依赖 M 层，提高了维护难度

注：iOS 在实际开发中过程中，我们往往不会严格遵循 MVC模式。通常需要 M、V 两层之间互通，比如 UITableViewCell 布局时，往往把数据封装到 Cell 中实现 Cell 的动态布局