App架構設計經驗談:業務層的設計

App架構設計經驗談:介面的設計
App架構設計經驗談:技術選型
App架構設計經驗談:資料層的設計
App架構設計經驗談:業務層的設計
App架構設計經驗談:展示層的設計

業務層其實並不複雜，但是大部分開發人員對其職責並沒有理解清楚，從而使其淪落為一個資料中轉站。我之前分享過的Android專案重構之路系列中提到的核心層，其實就是這裡所講的業務層。但有不少讀者反映，他們在實際專案中就只是做一下引數檢查，然後直接呼叫API，與展示層對接的介面基本也與API的介面一致的。這樣，業務層無疑就已經變為了一個資料中轉站。

業務層的職責

所以，設計業務層之前，對業務層的職責要先真正理解清楚。這裡，我舉兩個栗子說明一下。

第一個是新使用者註冊的例子。註冊時，介面上一般都會要求使用者輸入手機號、驗證碼、密碼和確認密碼。但是，API介面一般只會有三個引數：手機號、驗證碼和密碼，不會有確認密碼。因此，呼叫介面之前，密碼和確認密碼的一致性檢查是必須的。同時，也要檢查這些資料是否為空、手機號是否符合規範、驗證碼是否有效、密碼有沒有包含了特殊字元等。正確姿勢就是當所有檢查都通過了之後，才呼叫API介面。最後，呼叫註冊介面成功後，可能還要再呼叫一次登入介面，並可能將使用者登入資訊快取起來，方便使用者下次啟動應用時自動登入。所有這些都屬於業務邏輯處理，也就是業務層的工作。

第二個是涉及使用者驗證的例子。比如，在一個電商App，當使用者瀏覽某個商品，點選購買時，App首先會判斷使用者是否已經登入，如未登入，則會跳轉到登入頁面讓使用者先登入。如果已經登入，但token已經過期，那需要先去獲取新的token，之後才能進行下一步的購物操作。這些邏輯處理，也是業務層的工作。

因此，簡單點說，業務層就是處理業務邏輯，包括資料的檢查、業務分支的處理等。比如上面第二個例子，可能很多人就會將使用者是否已經登入的判斷直接在介面上做處理，當確認登入後，token也是有效的之後，才呼叫業務層做購買商品的操作，這就是導致業務層淪落為API的資料中轉站的直接表現。

業務層的互動

只有真正理解了業務層的職責之後，才能有效地設計業務層與外層的互動介面。

業務層向下，與資料層互動；向上，與展示層互動。

與資料層互動只是呼叫資料層的介面獲取資料，而與展示層互動則需要提供介面給展示層呼叫。因為業務處理一般屬於比較耗時的操作，主要在於底層的網路請求比較耗時，所以提供給展示層的介面資料結果應該以非同步的方式提供，因此，介面上就需要提供個回撥引數，返回業務處理之後的結果。我之前分享過的Android專案重構之路:實現篇有講到一種實現方式，可參考。

寫在最後

業務層可以說是一個資料加工場，處理核心的業務邏輯。其實，只要理解清楚了業務層的職責，業務層就不難實現。