MVC在界面开发中被奉为设计的典范，在移动开发中也是
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写。
它将业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
我刚接触ios，想通过ios的一些实例设计来理解MVC在ios中的应用。
1. IOS的view
对于工具化的图形界面设计，这个就应该是各种视图控件的设计，页面和控件的大小、位置、边框、颜色（前景、背景）、字体、title等属性的设置。
对于定制化的图形界面，仍然需要代码来设计页面和控件的大小、位置、边框、颜色（前景、背景）、字体、titile等属性。
UIView是ios视图设计中，最基本的一个类。里面很多属性需要定义。
与view紧密关联的数据就是viewcontroller了，view的刷新和输入提交都是通过controller来完成。
controller对view拥有控制权，简单来说，一个controller拥有访问其view实体的权利。
controller会拥有哪些权利？ 这就是controller与view不同的地方，代码相分离的地方。
2. iOS的controller
controller面对view的功能有：
能显示的修改view中的关联变量，驱动view的刷新。
能保存view中的关联变量，驱动model数据在服务端或cache的更新。
为实现一个完整的feature：
controller一般还拥有一些功能，如：
1. 逻辑处理、数据处理、错误处理等等
2. 与其他controller的交互
3. 访问server
4. 访问数据库
由以上功能来看，controller还能再分几层， 如逻辑层，cache层，server api call层（如rest）。
3. ios的Model
controller中使用的数据结构的定义。
Model的定义一般仅仅是POJO模式，定义一个对象的成员变量的 getter, setter函数。或者再增加一些通用的数据处理，如toJson, fromJson等
没有业务逻辑，是一个简单的实体类。
这个model一般与server protocol协议和数据库表 密切相关。
MVC的结构图
一些实践经验：
1. data model与server的protocol最好能分离。
一般情况下，data model可以与protocol共用一套数据结构。但这样的耦合会很不方便，protocol的变化会频繁影响到data model， 特别是类似json，和hibernate之类的变量名与资源和较强的关联关系时。
data model可以大而全，与protocol保持一定关联，但又能灵活分离。
所以，可以有一个data model模块，和一个 protocol模块。
当协议频繁改动时，旧协议可以不改变， data model也能做到适应新协议，并兼容老协议。
2. 移动端的data model的演化，字段的删除、增加都可以，但最好去除容易混淆的字段、重复意义的字段。
同一data model中，当不同业务各自的字段时，尽量去统一起来，可以由server端来维护和兼容新老协议。
3. 每个rest api call的protocol保持最小化，便于传输，功能分离等，并且保持一定的可扩展性。
对于最小化，将空对象null，空数组[]，在传输过程中过滤，并且对于protocol尽量不复用现有的嵌套对象，这样会令人confusing，会有很多深层嵌套和空白字段。
对于可扩展性，如 增加{}嵌套，便于扩展新的对象。