不論是前端,后臺,移動端,結(jié)合到現(xiàn)實生活中,處處都會涉及到框架的應(yīng)用,一個初期就設(shè)計優(yōu)良的架構(gòu),素容置疑在項目的可維護性,擴展性,健壯性肯定都有很大的提升蜜氨。所以我們必須要在開發(fā)之前在架構(gòu)上面多下功夫!
對于一個項目來說 架構(gòu) 一直是個值得關(guān)注的大話題, 這里我將其劃分為幾個部分去思考,設(shè)計艺栈。
文件目錄模塊架構(gòu), Coding設(shè)計模式層面架構(gòu) , 網(wǎng)絡(luò)層框架架構(gòu), 數(shù)據(jù)持久化架構(gòu), UIKit層面架構(gòu),暫時先以這幾個重要的層面去考慮,和設(shè)計廊敌。我們來依次討論這幾個模塊的理解和設(shè)計方案。
文件目錄模塊架構(gòu)
對于一個項目來說,最直觀的設(shè)計就是在文件目錄結(jié)構(gòu)上,一個好的文件目錄結(jié)構(gòu)劃分能讓我們自己在開發(fā)過程中更加快速編寫代碼,也能讓新加入的同事更快速的融入到項目中來,你想一下如果文件目錄劃分清晰明了,和一個雜亂無章的目錄結(jié)構(gòu),那個閱讀起來舒服因妙？其就像一本書的編寫排版,讀完排序之后讀者基本讀整本書內(nèi)容有一個清晰的認識,以及在后面閱讀起來隨時能通過排序來找到相應(yīng)的章節(jié).
所以在開發(fā)前期我們都應(yīng)該根據(jù)我們當前項目所有涉及到的業(yè)務(wù)場景,需要使用到的模塊心里都要有一個準備,參考了一些開源項目,以及網(wǎng)上關(guān)于項目目錄劃分的文章, 主流的劃分邏輯大概是分為兩種.
按項目內(nèi)每個大的模塊功能來進行文件夾劃分.
按主要的設(shè)計模式來進行劃分,例如: ViewController. View.Model VS ViewModel等.
個人更傾向于第一種, 舉個栗子. 以********支付寶********為例,項目 TabBar 分為 5 個大模塊, 一個是首頁,財富,口碑,朋友,我的. 然后在依次建立 5 個相應(yīng)的文件夾,當然還會有一些涉及功能很多的模塊,比如項目里面的商城,生活號,小程序等,雖然可能都包含在這 5 個大的模塊里面, 我們可以根據(jù)實際場景結(jié)合業(yè)務(wù), 如果某個模塊業(yè)務(wù)涉及場景和業(yè)務(wù)比較復(fù)雜, 都可以單獨為其建立一個獨立的文件夾, 與其他 5 個模塊進行平級別的劃分痰憎。
除了對模塊進行劃分外,我們在對項目里面肯定都會包含的網(wǎng)絡(luò)層,數(shù)據(jù)持久層,工具類庫層,三方資源層等等...這些在項目中使用率高的核心層面,也單獨劃分成一個文件夾的形式,方便以后新增代碼的時候,將其按功能點來添加和劃分。
這樣我們開發(fā)過程中查找相應(yīng)類文件,新增的時候也不會浪費太多的時間,也方便其他人閱讀攀涵。
設(shè)計模式層面架構(gòu)
這里主要是涉及到 設(shè)計模式的選擇上, 目前比較主流的有 MVC.MVVM.MVP铣耘。然后我參考了知名應(yīng)用 小猿搜題庫 出的設(shè)計模式架構(gòu)篇, 其主要是圍繞 MVC 和 MVVM 將其優(yōu)缺點進行一個優(yōu)良改造版. 在兩種架構(gòu)中權(quán)衡而產(chǎn)生的架構(gòu)MVVM without Binding with DataController, 我覺得很值得大家去參考,學(xué)習(xí).
關(guān)于在設(shè)計模式上, 我覺得還是應(yīng)該結(jié)合自己實際業(yè)務(wù)場景去進行選擇最好, 不需要太死板要求為了遵守這種設(shè)計模式而遵守。每一種設(shè)計都有其優(yōu)缺點, 我們應(yīng)該權(quán)衡其利與弊抱著學(xué)習(xí)的態(tài)度來對待, 只要其能真正解決我們的痛點就是一個好的設(shè)計模式, 在選擇上面我比較傾向于項目中多種設(shè)計模式公用的做法以故。 具體根據(jù)當前業(yè)務(wù)場景來蜗细。
網(wǎng)絡(luò)框架架構(gòu)
為什么要對網(wǎng)絡(luò)層進行封裝. 網(wǎng)絡(luò)層的代碼幾乎遍布我們每一個頁面, 想象一下假如我們不對網(wǎng)絡(luò)層進行一個良好的封裝, 每次調(diào)用原生庫 NSURLSession 來請求一段網(wǎng)絡(luò)大家會是什么心情？ 在想象一個每次我們請求網(wǎng)絡(luò)的時候基本都會添加一些公共參數(shù),緩存處理,統(tǒng)一錯誤碼等處理吧, 還有請求返回格式化設(shè)置等等. 這些都是基本很少變動的配置, 我們對其都做好封裝,上層直接傳入請求方法,URL,進來即可.
上面說的比較淺, 相信大家在項目中對網(wǎng)絡(luò)層封裝至少都 2 層以上, 本人主要是對 AFNetWorking 進行的一個封裝, 第一層封裝主要對 AFHttpSeesionManage 的初始化設(shè)置以及安全策略,證書校驗,還有請求超時處理等. 第二層則是直接獲取網(wǎng)絡(luò)的類,對其做了一些添加公共參數(shù),處理返回數(shù)據(jù)公共邏輯,返回結(jié)果錯誤碼,添加緩存,緩存處理等怒详。
這樣做的好處有幾點.
1. 假如有一天 AFNetWorking 不更新維護了, Apple 棄用了其最新版本的基于 NSURLSession 的網(wǎng)絡(luò)請求類, 我們可能需要考慮更換一個新的底層網(wǎng)絡(luò)庫. 我們只需要更改第一層封裝庫的代碼即可炉媒。 大大降低了對三方庫的依賴關(guān)系
2. 通過第一層封裝不僅完成了 降低依賴關(guān)系, 我們還做了公共的配置, 方便后續(xù)在做網(wǎng)絡(luò)請求時, 不需要再重新配置, 實現(xiàn)只配置一次即可共全局使用的效果踪区。 類似的第二層添加公共參數(shù)也是如此。
3. 第二層封裝主要是我們在實際業(yè)務(wù)場景中,基本每個網(wǎng)絡(luò)請求都會攜帶一些公共參數(shù), 比如當前項目版本號,設(shè)備號,時間等,后臺要求每次請求都要攜帶上這些公共參數(shù), 我們將其封裝起來橱野。
4. 處理請求結(jié)果錯誤碼,基本同理。
總結(jié):不寫重復(fù)的代碼善玫。
數(shù)據(jù)持久化架構(gòu)
由于項目是主打 IM 即時通訊的, 會涉及到很多數(shù)據(jù)都需要保存到本地, 以及讀取緩存的操作, 所以后期肯定要在數(shù)據(jù)緩存處理,數(shù)據(jù)讀取,數(shù)據(jù)存儲上做精心設(shè)計. 這一塊目前自己能力有限, 主要我們先參考大神文章為主. 留個坑, 后續(xù)我們在來補上, 希望有數(shù)據(jù)結(jié)構(gòu)設(shè)計,緩存處理方案的大神能指一二水援。
UIKit層面架構(gòu)
UIKit 層面涉及到的范圍也比較廣, 我主要從視圖控制器下手進行封裝, 采用 BaseViewController 的方式, 對 ViewController 和 UINavigationController 以及 UITabBarController 等進行一個 基類控制器的封裝, 將一些統(tǒng)一的參數(shù),業(yè)務(wù)等進行配置, 方便后續(xù)在項目中類似的控制器中, 直接通過集成 BaseViewController 就可以輕松實現(xiàn)的功能.
結(jié)語
作者水平有限,文中可能有說的不對,或者錯誤的地方歡迎大家指正。
主要是通過參考網(wǎng)上比較出名的文章,結(jié)合自己項目實際場景來進行,后續(xù)我會把自己看到的相關(guān)資料統(tǒng)統(tǒng)放下面供大家參考! 非常感謝這些大神,前輩為我們提供如此精辟的技術(shù)分享,如同一盞黑暗里的明燈,不斷指引我們走向光明大道茅郎！
參考資料:
iOS應(yīng)用架構(gòu)談 view層的組織和調(diào)用方案
淺析 iOS 應(yīng)用網(wǎng)絡(luò)層設(shè)計
iOS應(yīng)用架構(gòu)談 網(wǎng)絡(luò)層設(shè)計方案
onmyway133/fantastic-ios-architecture 設(shè)計模式架構(gòu)思想?yún)R總
老碼農(nóng)冒死揭開行業(yè)黑幕：如何編寫無法維護的代碼
優(yōu)秀的 iOS 應(yīng)用架構(gòu)：MVVM、MVC系冗、VIPER奕扣，孰優(yōu)孰劣
