原文：iOS應(yīng)用架構(gòu)談 view層的組織和調(diào)用方案
Casa在寫這個(gè)專題的時(shí)候，其實(shí)這個(gè)是比網(wǎng)絡(luò)篇要在前的，當(dāng)然我也是最先看到這一篇的，之所以我這樣寫，我是想按照程序開發(fā)，先構(gòu)想基礎(chǔ)部分，再展示view。所以，view篇，我自然覺得應(yīng)該在第二篇。好像很牽強(qiáng)的解釋。
view層的重要性，我在這里也不在重述了。
這里搬來casa的認(rèn)為不夠好的view層架構(gòu)原因：
1.代碼混亂不規(guī)范
2.過多繼承導(dǎo)致的復(fù)雜依賴關(guān)系
3.模塊化成都不夠高，組件粒度不夠細(xì)
4.橫向依賴
4.架構(gòu)設(shè)計(jì)失去傳承
那么一個(gè)好的view層，應(yīng)該怎么去做呢？
view代碼結(jié)構(gòu)的規(guī)定
制定一套代碼規(guī)范。
這樣的好處：
1.提高業(yè)務(wù)方View層的可讀性可維護(hù)性
2.防止業(yè)務(wù)代碼對架構(gòu)產(chǎn)生腐蝕
3.確保傳承
4.保持架構(gòu)發(fā)展的方向不輕易被不合理的意見所左右
這里確實(shí)是這樣的，我之前在一家互聯(lián)網(wǎng)金融公司，在2.0版本更新的時(shí)候，與同事一起協(xié)商定義了一套自己的規(guī)范。從而增加了后期的只修改view而不用去動(dòng)其他層的東西，1.0相對就差太多了。之后現(xiàn)在的公司，因?yàn)榉N種原因，未能協(xié)商溝通制定一個(gè)規(guī)范，而造成目前代碼越寫越多，而結(jié)構(gòu)已經(jīng)凌亂到誰開發(fā)，誰管理的地步。盡管已經(jīng)在其他方面做了優(yōu)化。但是換個(gè)人還需要看許久代碼。
這里viewController的代碼樣式，我就直接拉來Casa的截圖了。
這里的要點(diǎn)：
所有的屬性都使用getter和setter
不要在viewDidLoad里面初始化你的view然后再add，這樣代碼就很難看。在viewDidload里面只做addSubview的事情，然后在viewWillAppear里面做布局的事情，最后在viewDidAppear里面做Notification的監(jiān)聽之類的事情。至于屬性的初始化，則交給getter去做。
不過我個(gè)人還是喜歡用@property，在view里覺得getter和setter直接自動(dòng)生成，不是特殊處理的，有簡便的更多追求這樣的簡便整齊風(fēng)。
getter和setter全部都放在最后
每一個(gè)delegate都把對應(yīng)的protocol名字帶上，delegate方法不要到處亂寫，寫到一塊區(qū)域里面去
event response專門開一個(gè)代碼區(qū)域
關(guān)于private methods，正常情況下ViewController里面不應(yīng)該寫
這樣的要點(diǎn)，應(yīng)該大家一看就懂吧，不過，最后一點(diǎn)小功能要么把它寫成一個(gè)category，要么把他做成一個(gè)模塊，哪怕這個(gè)模塊只有一個(gè)函數(shù)也行。獨(dú)立出來更好。
關(guān)于View的布局
Casa也建議用Masonry，確實(shí)好用，不過一些小的細(xì)節(jié)需要注意些，這個(gè)我回頭會(huì)寫個(gè)總結(jié)，走過的坑。
何時(shí)使用storyboard，何時(shí)使用nib，何時(shí)使用代碼寫View
我一直在用純手寫代碼，有時(shí)候會(huì)忘記storyboard，nib怎么去寫了。純代碼寫的好處，文中還有唐巧的博客也有提到。多人合作還是選擇純手工寫會(huì)省下很多處理沖突的時(shí)間。雖然在編寫的時(shí)候慢，但是這個(gè)時(shí)間比起合代碼帶來的沖突處理要快太多了。
是否有必要讓業(yè)務(wù)方統(tǒng)一派生ViewController
我同casa的意見保持一致。
而且Casa提出了使用AOP
關(guān)于MVC、MVVM等一大堆思想
這個(gè)還是看文章，寫的很細(xì)致，我在互金的時(shí)候，也直接用上了MVVM，弱化了viewcontroller，減小了model，對于view更新快，業(yè)務(wù)邏輯并不會(huì)更變太多，是一個(gè)極其方便的架構(gòu)。
