View代码结构的规定
1.提高业务方View层的可读性可维护性
2.防止业务代码对架构产生腐蚀
3.确保传承
4.保持架构发展的方向不轻易被不合理的意见所左右
ViewController的代码应该差不多是这样：
要点如下：
所有的属性都使用getter和setter
而不是这样：
先是life cycle，然后是Delegate方法实现，然后是event response，然后才是getters and setters。这样后来者阅读代码时就能省力很多。
1.每一个delegate都把对应的protocol名字带上，delegate方法不要到处乱写，写到一块区域里面去
2.event response专门开一个代码区域，所有button、gestureRecognizer的响应事件都放在这个区域里面，不要到处乱放。
3.关于private methods，正常情况下ViewController里面不应该写。这个private methods一般是用于日期换算、图片裁剪啥的这种小功能。这种小功能要么把它写成一个category，要么把他做成一个模块，哪怕这个模块只有一个函数也行。
MVC
UIViewController中自带的那个view，它的主要任务就是作为一个容器，我也觉得苹果做的这个选择是非常正确明智的。Controller可以因为不同事件的产生去很方便地更改容器内容，比如加载失败时，把容器内容换成失败页面的View，无网络时，把容器页面换成无网络的View等等。
在iOS开发领域中，怎样才算是MVC划分的正确姿势？
M应该做的事：
1.给ViewController提供数据
2.给ViewController存储数据提供接口
3.提供经过抽象的业务基本组件，供Controller调度
C应该做的事：
1.管理View Container的生命周期
2.负责生成所有的View实例，并放入View Container
3.监听来自View与业务有关的事件，通过与Model的合作，来完成对应事件的业务。
V应该做的事：
1.响应与业务无关的事件，并因此引发动画效果，点击反馈（如果合适的话，尽量还是放在View去做）等。
2.界面元素表达
