(iOS开发总结)MVC模式-CSDN博客

一、MVC 模式

MVC，即模型-视图-控制器(Model-View-Model)，是软件开发中应用甚广的一种设计模式。其用意是将数据与视图分化，利用模型数据控制视图的显示，但两者的交互由控制器控制。在iOS开发中，MVC模式应用很广，是iOS控件设计的主要模式之一。

UITableView与UICollectionView 可以说是iOS开发中最能体现MVC模式的两种控件，以下举UITableView为例，其中UITableViewCell是做显示任务的View，那么每行UITableViewCell都显示数据源（Datasource）对应的数据，如果把每行显示的数据封装成对象，那么我们把它们称为模型对象（模型数据Model）。

二、模型对象(Model)的封装

即使不把数据封装成对象，我们常见的就是字典(NSDictionary)和数组(NSArray)，也能按部就班把数据布局到UITableViewCell上，一定层面上来说也是MVC模式。但为什么不把它封装成对象呢？有时候，数据的某些字段不能直接布局到View中显示，特别是遇到复杂的数据结构，这时封装成对象的好处就体现了，我们可以在对象中处理这些字段后再显示到View上。封装成对象，更加利于我们控制业务处理和编码，这可是在面向对象编程。

通常我们把数据封装成对象并不是难事儿，如果每行UITableViewCell显示的“布局格式”一样，直接对应把数据布局上去就行，某种意义上来说，UITableViewCell已经事先知道要显示什么了。比如微信的通讯录，就显示头像和名字，所以UITableViewCell“格式”事先已被确定，压根就不需要改变自己来适应显示下一条通讯成员。

但有些时候，每行UITableViewCell显示的“布局格式”都不一样，UITableViewCell永远不知道下一条到底要怎样布局，比如微博，UITableViewCell不知道下一条微博有没有转发，有没有图片，有图片的话有几张等等。那这时候应该怎样布局？

可以观察到，微博的数据格式是一定的，就是说一条什么都有（转发、图片等）的微博，这时候UITableViewCell中的子控件个数达到饱满，无论数据要显示什么，都有子控件可以显示。但如果有一条微博比如少了图片，那么要么remove这个显示图片的View，要么将这个显示图片的View的Frame设为CGRectZero（那么View的布局格式（如果我们把子空间的位置称为“布局格式”）也是确定的，只是subview的Frame在变）。可想而知只要将缺少的那些字段对应的View的Frame设为CGRectZero即可，不用反复移除添加subview (UITableViewCell 是采取循环回收利用的)。

这里有个问题，根据上面一段思路，可以自定义UITableViewCell,然后引用一个模型对象并重写其setter方法，在setter方法中拿到模型对象根据数据计算subview.frame并布局，缺少的字段对应的View.frame直接设为0。但是这样一来，上拉加载数据的时候需要时间计算Frame，那么界面效果会显卡，而且当回滚的时候又进行重复的计算工作。这时需要再新建一个模型(姑且称之为Handler模型)，让它引用微博模型，然后将对微博模型的处理还有各个subview的frame的计算封装到Handler模型中，而自定义UITableViewCell则引用Handler模型。那么在加载数据的时候，该模型拿到微博模型数据在setter中即可计算subview.frame，这时UITableViewCell的subview的frame已经准备好，自定义UITableViewCell的模型的setter中直接布局和赋值数据（Handler模型引用着微博模型）

三、视图（View）的封装

根据模型对象（Model）的封装的介绍，遇到复杂的UITableView通常会自定义Cell，把不变的界面因素在初始化创建的时候就可以写定，动态的界面因素留给模型去控制。自定义UITableViewCell，让它引用模型对象并在其setter中布局并赋值，如果subview.frame仍不确定，则再封装一个Frame模型并引用模型对象，让自定义Cell引用F模型对象并在setter中布局。

以上两种布局其实可以看成是一种，即UITableViewCell中的subviews的布局都是一定的了，即使是subview.frame为CGRectZero，但这个subview还必须存在，否则加载的时候会增加开销。
这里还有另外一种App常见的界面布局，即类似微信收藏的布局，每个UITableViewCell都属于一个类型，有图片、视频、文档等等，我尝试按照处理微博的方法来解决问题，但效果不如意。微信收藏这种布局参杂很多种类型，每个UITableViewCell只显示一种类型数据，显示了一种数据则一定不会有其它类型数据，如果按照微博数据处理方式处理，则在frame赋值的时候有一大串判断和CGRectZero,每每增加一种类型，就要修改源文件增加判断，处理要特别全面否则容易出现bug。尝试处理方法是自定义各种类型的UITableViewCell对应各种类型数据，给每种类型的UITableViewCell给定不同的Identifier。这样，图片只会被布局到图片Cell，文档只会被布局到文档Cell。