[[413918]]

互聯網分層架構演進有兩條核心原則：

• 讓上游更高效的獲取與處理數據(復用);
• 讓下游能屏蔽數據的獲取細節(封裝);

數據從數據庫/緩存層，到微服務層，到站點應用層，最終都匯聚到客戶端。服務端的分層架構設計已經講了很多，客戶端的分層架構設計應該怎么玩呢，服務端的分層架構設計是否有能夠借鑒的地方呢，今天和大家簡單聊一聊。

先來看小詩一首：

《Android猿》

曾經

  所有代碼

  都被寫在Activity里

幾乎

  沒有代碼

  可以復用

每當

  看到Activity里

  2000行的函數

我就

  想要離職

上面，是團隊中一個文藝Android程序員的自述，表達的核心觀點是：幾乎所有代碼都寫在了Activity里(不理解Activity的，暫且認為是MVC里的view層)，完全沒有封裝和復用。

假設一個具體的例子，微信登錄的界面，點擊登錄按鈕，此時可能要執行：

• 驗證用戶名密碼;
• 拉取好友列表;
• 拉取用戶信息;
• 拉取好友信息;
• 拉取離線消息;
• ...

畫外音：那個大月亮的畫面，要卡很久。

如果把這些都寫在微信“登錄Activity”里，會發現一些很嚴重的問題：

• 登錄整個邏輯不能復用;
• 登錄過程中的每個子邏輯也無法復用;

假設產品里有一個“離線后重新登錄”的功能，步驟與登錄相同，就需要把上述在“重新登錄Activity”里代碼復制一遍。

又假設產品里有一個地方需要“拉取用戶信息”，也將把“登錄Activity”里“拉取用戶信息”的代碼復制一遍。

封裝復用的道理誰都懂，拷貝代碼的壞處也誰都明白，那為什么大家還這么做，代碼越來越“腐爛”呢?

根據個人經驗，主要是這么幾點原因：

(1)早期業務壓力大，APP是少數幾個同學的，沒有提前做規劃;

(2)后期代碼越來越臃腫，不敢動，一動怕影響功能，怕出問題，怕擔責任;

(3)項目中，是以功能界面進行編碼劃分的，一個同學會同時負責MVC三部分編碼，加之項目壓力又大，既然是一個人寫，就沒必要分層了，搞多了調用反而麻煩;

(4)項目中，有個需求好像之前做過，代碼一看，寫在Activity里，糾結。抽象成函數?還得改別人的代碼，算了，還是拷貝一份吧;

(5)…

不管歷史原因，項目原因，個人的原因，大家都知道分層抽象，代碼復用是正確的，那有什么方案能夠將這個分層抽象落地，從后端的分層架構中是否有可借鑒的地方呢?

一個典型業務系統的后端架構如上：

• web-server層調用RPC接口，從service層獲取數據，拼裝html/json，完成數據展現;
• biz-service/data-service向上游提供可復用的原子接口，實現業務邏輯，并通過DAO層，從db層獲取數據;
• db層提供數據;

APP端的分層架構不是非常相似么?

還是以登錄業務為例：

(1)登錄Activity有兩個按鈕，一個確認按鈕，一個取消按鈕，這兩個按鈕的點擊，分別只能調用一個函數：

• on_LoginConfirm_Click
• on_LoginCancel_Click

這里相當于展現層，除了交互與展現，View層只能調用這兩個函數。

(2)這兩個函數的實現，是通過若干可復用的“原子業務邏輯”函數實現的：

• 驗證用戶名密碼：bool verifyPass(name, pass)
• 拉取好友列表：ListgetFriendList(uid)
• 拉取用戶信息：Use rgetUserInfo(uid)
• 拉取好友信息：ListgetUserInfo(List)
• 拉取離線消息：ListgetOfflineMst(uid)

這相當于服務層，實現業務邏輯，提供封裝和復用

(3)“原子業務邏輯”函數執行的過程中，需要訪問數據，數據的獲取又分為兩類：

• 同步獲取：通過文件，內存，本地數據庫獲取
• 異步獲取：從server獲取，往往通過回調實現

這里相當于數據層，向上游屏蔽數據獲取的復雜性，分別用不同的Proxy去實現。

在這種結構下：

(1)展現層非常輕，只調用一個函數，用于展現數據;

(2)“原子業務邏輯”可以復用，不同的展現層Activity可以隨意組合，實現不同的業務邏輯，用于處理數據;

(3)Proxy對上游屏蔽的數據獲取的復雜性，向上游提供數據獲取接口，用于獲取數據;

分層架構封裝復用的思想，前后端有共通的地方。

Activity里一坨坨復雜的代碼，也是你曾經的痛么?

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文