iOS进阶之架构设计MVC（1）

做iOS开发已经有5个年头了，应用开发已经比较熟练了，也来到了一个迷茫的阶段，彷佛触到了技术天花板。其实心知肚明，业务功能实现是比较得心应手了，但是在更高级的顶层设计方面还欠缺的很多。因此，必须转变思想，不能再从实现功能角度来提高自己的技术，而是要从实现的方法，方式上提高自己。写出具有通用性、灵活性、隔离性等角度的代码。多看源码。从头梳理一下框架设计知识。

前言
MVC是软件工程中的一种软件架构模式，它把软件系统分为三个基本的部分：模型Model、视图View以及控制器Controller。这种模式的目的是为了实现一种动态的程序设计，简化后续对软件系统的修改和扩展，并使得程序的某一部分的复用成为可能。三个部分按照其各自的职责划分：

• 数据Model： 负责封装数据、存储和处理数据运算等工作
• 视图View： 负责数据展示、监听用户触摸等工作
• 控制器Controller： 负责业务逻辑、事件响应、数据加工等工作

MVC 框架设计模式

• Model层: 模型对象封装了应用程序的数据，并定义操控和处理该数据的逻辑和运算。

• View层: 视图对象是应用程序中用户可以看见的对象。视图（View）是控制器的侍从，是控制器要使用的类，用于构建UI。

• Controller层: Model 与 View层的中介，把Model数据在View上展示出来。控制器对象：控制模型呈现在屏幕上。

目的: 低耦合，可复用

MVC的架构模式图：

MVC 各层之间的通信

• Controller要完全知道Model的内容，不受限制地访问Model；相反，Model 通过 Notification 和 KVO 机制与 Controller 间接通信。
• Controller也能与View通信，如通过outlet；相反View也能与Controller通信，但是View是通用的，所以它不能对Controller的类知道得太多，只能以一种“盲”的方式去通信，如关联一个action、委托（delegate）协议。
• Model 和 View 永远不能相互通信，只能通过 Controller 传递。

在传统的MVC结构中，数据层在发生改变之后会通知视图层进行对应的处理，视图层能直接访问数据层。但在iOS中，M和V之间禁止通信，必须由C控制器层来协调M和V之间的变化。如下图所示，C对M和V的访问是不受限的，但M和V不允许直接接触控制器层，而是由多种Callbacks方式来通知控制器。

缺点：

• 导致Controller臃肿，代码特别多，视图一复杂起来，代码量过长，不好维护；
• 写在Controller里View的代码无法复用；

MVC 的示例demo

比较简单不再举例。就是你把View 声明和数据请求写到Controller 的臃肿写法。
贴出2个写的很好典型的示例：
iOS MVC实例讲解
iOS通用的MVC模式项目框架MobileProject

参考文章

MVC 模式
iOS架构入门 - MVC模式实例演示
浅谈iOS中MVC