(iOS开发总结)MVC模式

一、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)的封装

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

    以上两种布局其实可以看成是一种,即UITableViewCell中的subviews的布局都是一定的了,即使是subview.frame为CGRectZero,但这个subview还必须存在,否则加载的时候会增加开销。

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

你可能感兴趣的:((iOS开发总结)MVC模式)