之前有對(duì)iOS認(rèn)知中做過(guò)一次簡(jiǎn)單的分析
https://my.oschina.net/u/1391235/blog/701417
既然說(shuō)是架構(gòu)：那么這邊要考慮到的是整個(gè)項(xiàng)目，如果是一個(gè)層次簡(jiǎn)簡(jiǎn)單單的項(xiàng)目，對(duì)于架構(gòu)來(lái)說(shuō)也沒(méi)有非常大的體現(xiàn)意義，個(gè)人認(rèn)為，架構(gòu)就是能為 業(yè)務(wù)邏輯復(fù)雜的項(xiàng)目塑性，好的架構(gòu)不僅層次清晰，開(kāi)發(fā)過(guò)程也應(yīng)該是愉快輕松的，不是重復(fù)的碼代碼！
先從大的方面來(lái)講：
一個(gè)App分為 網(wǎng)絡(luò)層(Server)、數(shù)據(jù)庫(kù)層(DataBase)、 應(yīng)用層(Application)
三者之間的關(guān)系，如上圖所展示
三者之間關(guān)系的實(shí)現(xiàn)：采用經(jīng)典的工廠模式(ServiceFactory)來(lái)松耦合：以不同的功能模塊來(lái)劃分，如：
圖中Sevice是提供了獲取系統(tǒng)權(quán)限和用戶邏輯相關(guān)的接口服務(wù)，隨著業(yè)務(wù)的增加，項(xiàng)目不斷的完善，Service會(huì)不斷的龐大起來(lái)，一般以功能來(lái)增加不同的服務(wù)。
網(wǎng)絡(luò)層指的是:和服務(wù)器的交互，一般封裝了第三方的網(wǎng)絡(luò)實(shí)現(xiàn)，一個(gè)方法一個(gè)CallBack，在Service中的某個(gè)功能下的Protocol實(shí)現(xiàn)；
數(shù)據(jù)庫(kù)指的是：用戶對(duì)數(shù)據(jù)的操作或響應(yīng)服務(wù)器做出響應(yīng)修改，一般底層都做了封裝，暴露出行為功能的接口（增刪改查等）
下面來(lái)說(shuō)下一個(gè)重要的類UIResponder：
其中這張圖片包含了一個(gè)重要的思想，事件追蹤，它可以在我們觸發(fā)的那個(gè)類里，發(fā)出事件信號(hào)，可以一直追蹤到controller這一層。
這在我們寫(xiě)業(yè)務(wù)的時(shí)候，是個(gè)非常巧妙的事情。
接下來(lái)從小的方面Controller來(lái)解說(shuō)架構(gòu)：
一個(gè)App也是由多個(gè)Controller的組合而成，Controller最重要的是UI元素、邏輯和交互。如何處理好這些關(guān)系至關(guān)重要。我們現(xiàn)在比較流行的架構(gòu)是將邏輯(presenter/businessLogic)和交互(interactor)分離出Controller，避免了Controller的臃腫，也有將View分離出去的。（架構(gòu)VIPER，CDDContext等）
站在了已有的架構(gòu)的基礎(chǔ)上，做了一些修改。
如上圖，PBMainController是一個(gè)主界面，里面也按Presenter、Interactor和View來(lái)劃分，但是這里比正常的架構(gòu)多了一個(gè)Protocol文件，這個(gè)是對(duì)應(yīng)于Controller、Presenter、Interactor和View，增加這些協(xié)議類，是為了降低這4者之間的耦合度，因?yàn)樵趯?shí)際開(kāi)發(fā)過(guò)程中，隨著項(xiàng)目的迭代，類會(huì)越來(lái)越龐大，代碼量也越來(lái)越多，如果將類的public方法或?qū)傩远紝?xiě)在.h中，代碼的安全性就更差，團(tuán)隊(duì)中的其他成員可能在不清楚你的代碼塊的作用下，就修改了代碼，這邊就將類于類之間的邏輯關(guān)系都寫(xiě)到了Protocol中，在對(duì)應(yīng)的.m里去實(shí)現(xiàn)。
在Controller.h中對(duì)應(yīng)的Presenter、Interactor和View都是readonly屬性，這樣能保護(hù)它們不受外部類影響，且他們對(duì)應(yīng)的baseController都是指向當(dāng)前的Controller，其他子View可以通過(guò)UIResponder的特性獲取到指向當(dāng)前的Controller；
在上面的Main結(jié)構(gòu)圖可以看到：PBTestSubView是PBMainView中的一個(gè)view, testButton是PBTestSubView中的一個(gè)UIButton，那么點(diǎn)擊testButton，跳轉(zhuǎn)到另外一個(gè)界面，正常的App可能是通過(guò)兩個(gè)Delegate或者NSNotification來(lái)實(shí)現(xiàn)。但是如果用Protocol和baseController來(lái)實(shí)現(xiàn)，那就是在testButton點(diǎn)擊的時(shí)候，能之間將事件傳遞到指定的Controller，再獲取到對(duì)應(yīng)的Interactor，這樣的實(shí)現(xiàn)是不是簡(jiǎn)單很多？
我們利用UIResponder的特性，可以在任何一個(gè)它的子...子控件里追蹤到存放它的當(dāng)前Controller，從而實(shí)現(xiàn)界面跳轉(zhuǎn)。這樣代碼看起來(lái)是不是很簡(jiǎn)潔明了？層次也是很清楚。
總結(jié)：站在前人的基礎(chǔ)上，修改了下架構(gòu)，還是比較容易的。
這個(gè)架構(gòu)的思想：
大的方面是工廠模式，Service 管理了 數(shù)據(jù)層、網(wǎng)絡(luò)層、和應(yīng)用層之間的關(guān)系。
小的方面利用UIResponder、Protocol 結(jié)合之前網(wǎng)絡(luò)上的框架來(lái)松耦合。
架構(gòu)層次很明顯，主體框架代碼我們可以寫(xiě)個(gè)腳本來(lái)生成，這樣可以避免大量碼代碼的時(shí)間，而且也不易出錯(cuò)。
在gitHub上給出了一個(gè)Demo
Demo中應(yīng)該能看到這個(gè)架構(gòu)的整個(gè)思想，具體的數(shù)據(jù)庫(kù)和網(wǎng)絡(luò)的管理也是要分層的，它們應(yīng)該在service下面的,demo中沒(méi)有寫(xiě)了，有時(shí)間后續(xù)會(huì)完善demo。
