一個App，從根本上來說，就是對數(shù)據(jù)的處理，包括數(shù)據(jù)從哪里來、數(shù)據(jù)如何組織、數(shù)據(jù)怎么展示，從職責上劃分就是：數(shù)據(jù)管理、數(shù)據(jù)加工、數(shù)據(jù)展示。相對應(yīng)的也就有了三層架構(gòu)：數(shù)據(jù)層、業(yè)務(wù)層、展示層。本文就先講講數(shù)據(jù)層的設(shè)計。
數(shù)據(jù)層，是三層架構(gòu)中的最底層，負責數(shù)據(jù)的管理。它主要的任務(wù)就是：
調(diào)用網(wǎng)絡(luò)API，獲取數(shù)據(jù)；
將數(shù)據(jù)緩存到本地；
將數(shù)據(jù)交付給上一層。
根據(jù)這三個任務(wù)，數(shù)據(jù)層可以再拆分為三層：網(wǎng)絡(luò)層、本地數(shù)據(jù)層、交付層。
網(wǎng)絡(luò)層
網(wǎng)絡(luò)層主要就是對網(wǎng)絡(luò)API的封裝。關(guān)于API的設(shè)計，該系列的第一篇文章接口的設(shè)計已經(jīng)講過一些。關(guān)于如何封裝，可以參考Android項目重構(gòu)之路系列的架構(gòu)篇和實現(xiàn)篇，其中接口層和本文的網(wǎng)絡(luò)層是一樣的。
還有一些在前面的文章中沒有提及到的，在此做一些補充。
首先是不同網(wǎng)絡(luò)狀態(tài)的處理。當網(wǎng)絡(luò)不可用時，則不應(yīng)該再去調(diào)用API；當網(wǎng)絡(luò)可用，但不是WIFI時，有些比較耗流量的操作也應(yīng)該禁止，比如上傳和下載大文件；當網(wǎng)絡(luò)狀態(tài)不同時，還可以采用不同的網(wǎng)絡(luò)策略，比如，當網(wǎng)絡(luò)為WIFI時，當前API可以返回更多更全面的數(shù)據(jù)，還可以預(yù)先加載相關(guān)聯(lián)的其他API。
其次，為了節(jié)省流量，接口的設(shè)計上可以對數(shù)據(jù)進行簡化。例如，對于一些列表類的接口，可以這么設(shè)計：只返回更新的部分，比如，上一次請求返回了10條按時間排序的數(shù)據(jù)，第一條數(shù)據(jù)為最新的，id為101，當發(fā)起下一次請求時，將101的id作為參數(shù)調(diào)用API，API查到該id，發(fā)現(xiàn)該id之后又新增了兩條數(shù)據(jù)，API則只返回新增的這兩條數(shù)據(jù)。
另外，為了保證程序的健壯性，調(diào)用API時，對入?yún)⒌暮戏ㄐ詸z查也是很有必要的。而且，也應(yīng)該定義好本地的錯誤碼和錯誤信息，保證每個錯誤都能正常解析。
本地數(shù)據(jù)層
本地數(shù)據(jù)層主要就是做緩存處理，這需要設(shè)計好一套緩存策略。設(shè)計緩存策略時，有幾個問題需要考慮清楚：
哪些需要緩存？哪些不需要緩存？
緩存在哪里？數(shù)據(jù)庫？文件？還是內(nèi)存？
緩存時間多長？
哪些需要緩存？
將所有數(shù)據(jù)都緩存是不明智的，不同的數(shù)據(jù)應(yīng)該有不同的緩存策略，比如一個電商App，首頁的商品列表數(shù)據(jù)應(yīng)該緩存，而且緩存時間應(yīng)該比較長，而每個商品的詳情數(shù)據(jù)就沒必要緩存或緩存時間很短。對于一份數(shù)據(jù)需不需要緩存，判斷標準可以是：用戶查看該數(shù)據(jù)的頻率高不高？首頁商品列表是用戶每次啟動都會看到的，而每個商品的詳情用戶最多只看幾次。
緩存在哪里？
從內(nèi)存讀取數(shù)據(jù)是最快的，但內(nèi)存非常有限。因此，內(nèi)存一般只用來緩存使用頻率非常高的數(shù)據(jù)。
文件緩存主要就是圖片、音頻、視頻了。
數(shù)據(jù)庫可以保存大量數(shù)據(jù)，主要就是用于保存商品列表、聊天記錄之類的關(guān)系型數(shù)據(jù)。
然而，不管緩存在哪里，都需要限定好緩存的容量，要定期清理，不然會越積越多。
緩存時間多長？
首先，每份緩存數(shù)據(jù)都應(yīng)該設(shè)置一個緩存的有效時間，有效期的起始時間以最后一次被調(diào)用的時間為準，當該數(shù)據(jù)長時間沒有再被調(diào)用到時，就應(yīng)該從緩存中清理掉。
緩存的有效時間應(yīng)該設(shè)多長呢？可以短至一分鐘，長至一星期甚至一個月，具體因數(shù)據(jù)而異。一般內(nèi)存的緩存時間不宜太長，程序退出基本就要全部清理了。文件緩存可以設(shè)置保留一天或一個星期，可以每隔一天清理一次。數(shù)據(jù)庫緩存再久一些也無所謂，但最好還是不要超過一個月。
交付層
交付層其實就是一個向上層開放的交互接口層，是上層向數(shù)據(jù)層獲取數(shù)據(jù)的入口。上層向數(shù)據(jù)層請求數(shù)據(jù)，它是不關(guān)心數(shù)據(jù)層的數(shù)據(jù)是從緩存獲取還是從網(wǎng)絡(luò)獲取的，它只關(guān)心結(jié)果，數(shù)據(jù)層能給到它想要的數(shù)據(jù)結(jié)果就OK了。因此，交付層主要就是定義一堆開放的接口或協(xié)議。
如果接口或協(xié)議非常多，那么，將接口或協(xié)議按照模塊劃分也是有必要的。比如微信，按模塊劃分有：IM、公眾號、朋友圈、錢包、購物、游戲等等。模塊之間應(yīng)該盡量相對獨立、松耦合。
寫在最后
數(shù)據(jù)層如果再擴展，還可以再加入日志管理，這里就不再展開講了。上面內(nèi)容講得也比較亂，有哪里講得不好的地方歡迎吐槽。
原創(chuàng)文章，轉(zhuǎn)載請注明：轉(zhuǎn)載自Keegan小鋼
