关于代码风格的一些看法

1 UIViewController和UIView

Controller顾名思义,主要是用来作控制的,View是用来作UI展现的.但在实际的开发中,每每会将Controller和View都做为UI层来展现,这样作会有什么问题?

a)View将不光负责展现控件,还须要处理业务数据,业务逻辑.对于一个业务逻辑很强的View这样作还能够,好比用户的头像控件,就是和用户我的资料有很强业务关系的,这种作法是合理的.但若是是一个普通的View,好比一个底部工具条,里面有不少按钮,显然再用View处理业务逻辑和数据是不合理的,这样的View是无法复用的,若是你说:我不复用View,那就呵呵了.

b)Controller里面可能存在大量的UI控件,各类建立控件的代码,各类代理,回调,数据读取,网络请求,业务数据适配,这样的ViewController将会变得很是庞大.ViewController就是一个页面,一个完整的页面,要用ViewController就是想用些和生命周期有关的ViewController特有的东西,若是只是经过ViewController加载一个view,那最好直接用view.一般来说ViewController是不可以复用的,若是你从StoryBoard中连了不少控件到ViewController中,而那个StoryBoard中要是还有不少约束,那随着业务的发展,这份代码离没法维护的日子就不远了.

那Controller应该作什么:

1 初始化UI(极少了的UI细节,各类自定义UIView)

2 addObserver 设置delegate,可能还有addTag,addGesture(极少的)

3 同步取本地数据,异步取网络数据.(UI展现的数据,即便是同步数据也不该该在Controller里初始化),对于数据,这里应该是封装了的数据,也就是说,一个View对应一个Model,而不该该是零散的数据,拼凑的.

4 在代理和observer的回调中更新UI,这里的更新UI只要1句话,把数据全都经过View的public interface 丢给View,至于View想用什么,想怎么更新,都是它本身的事情(这里的View包括自定义的TableViewCell,CollectionViewCell,自定义的View),固然对于部分更新UI仍是要在View中暴露几个public property.

5 若是你使用自动布局或者Masonry要手动码一些addConstraints这样相似的代码,或者你使用frame,那你要在viewDidLayoutSubviews设置每一个view的frame

6 最核心的部分,负责页面的跳转,跳转也就是一句话,[XXXViewController xxx:];这里须要在ViewController里面实现一个或者多个类方法,方便外部调用和传递参数,这里参数仍是建议封装成一个model,只传一个参数,里面具体是什么本身去解析.这里ViewController只关心跳哪里,具体怎么跳,不须要写在本ViewController里.

7 动态展现一些子view,alertView,messageBox, 这里是把ViewController弄乱的最好的地方,由于动态添加的view多是动画,因此尽可能把view中动画有关的东西都封装到view中,ViewController只经过1-2句代码建立View并完成动画,而View给ViewController传递消息和数据通通都经过代理的方式,最后ViewController只要在某个代理里remove这个view就能够了.

因此整个ViewController写下来import的东西应该是相似这样的

#import "XXXViewController.h"

#import "XXXModel.h"

.....

#import "XXXView.h"

....

#import "XXXViewCell.h"

....

至于从model中获取的数据不是view要显示的数据应该怎样作数据的适配呢?这里就要使用到ViewModel,为避免文章过长,下一篇详细说明如何在已有的big VC中增长VM来瘦身VC.