原文：iOS应用架构谈 view层的组织和调用方案
Casa在写这个专题的时候，其实这个是比网络篇要在前的，当然我也是最先看到这一篇的，之所以我这样写，我是想按照程序开发，先构想基础部分，再展示view。所以，view篇，我自然觉得应该在第二篇。好像很牵强的解释。
view层的重要性，我在这里也不在重述了。
这里搬来casa的认为不够好的view层架构原因：
1.代码混乱不规范
2.过多继承导致的复杂依赖关系
3.模块化成都不够高，组件粒度不够细
4.横向依赖
4.架构设计失去传承
那么一个好的view层，应该怎么去做呢？
view代码结构的规定
制定一套代码规范。
这样的好处：
1.提高业务方View层的可读性可维护性
2.防止业务代码对架构产生腐蚀
3.确保传承
4.保持架构发展的方向不轻易被不合理的意见所左右
这里确实是这样的，我之前在一家互联网金融公司，在2.0版本更新的时候，与同事一起协商定义了一套自己的规范。从而增加了后期的只修改view而不用去动其他层的东西，1.0相对就差太多了。之后现在的公司，因为种种原因，未能协商沟通制定一个规范，而造成目前代码越写越多，而结构已经凌乱到谁开发，谁管理的地步。尽管已经在其他方面做了优化。但是换个人还需要看许久代码。
这里viewController的代码样式，我就直接拉来Casa的截图了。
这里的要点：
所有的属性都使用getter和setter
不要在viewDidLoad里面初始化你的view然后再add，这样代码就很难看。在viewDidload里面只做addSubview的事情，然后在viewWillAppear里面做布局的事情，最后在viewDidAppear里面做Notification的监听之类的事情。至于属性的初始化，则交给getter去做。
不过我个人还是喜欢用@property，在view里觉得getter和setter直接自动生成，不是特殊处理的，有简便的更多追求这样的简便整齐风。
getter和setter全部都放在最后
每一个delegate都把对应的protocol名字带上，delegate方法不要到处乱写，写到一块区域里面去
event response专门开一个代码区域
关于private methods，正常情况下ViewController里面不应该写
这样的要点，应该大家一看就懂吧，不过，最后一点小功能要么把它写成一个category，要么把他做成一个模块，哪怕这个模块只有一个函数也行。独立出来更好。
关于View的布局
Casa也建议用Masonry，确实好用，不过一些小的细节需要注意些，这个我回头会写个总结，走过的坑。
何时使用storyboard，何时使用nib，何时使用代码写View
我一直在用纯手写代码，有时候会忘记storyboard，nib怎么去写了。纯代码写的好处，文中还有唐巧的博客也有提到。多人合作还是选择纯手工写会省下很多处理冲突的时间。虽然在编写的时候慢，但是这个时间比起合代码带来的冲突处理要快太多了。
是否有必要让业务方统一派生ViewController
我同casa的意见保持一致。
而且Casa提出了使用AOP
关于MVC、MVVM等一大堆思想
这个还是看文章，写的很细致，我在互金的时候，也直接用上了MVVM，弱化了viewcontroller，减小了model，对于view更新快，业务逻辑并不会更变太多，是一个极其方便的架构。
