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

原文出處： Keegan小鋼   

業務層其實並不複雜，可是大部分開發人員對其職責並無理解清楚，從而使其淪落爲一個數據中轉站。我以前分享過的Android項目重構之路系列中提到的核心層，其實就是這裏所講的業務層。但有很多讀者反映，他們在實際項目中就只是作一下參數檢查，而後直接調用API，與展現層對接的接口基本也與API的接口一致的。這樣，業務層無疑就已經變爲了一個數據中轉站。

業務層的職責

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

第一個是新用戶註冊的例子。註冊時，界面上通常都會要求用戶輸入手機號、驗證碼、密碼和確認密碼。可是，API接口通常只會有三個參數：手機號、驗證碼和密碼，不會有確認密碼。所以，調用接口以前，密碼和確認密碼的一致性檢查是必須的。同時，也要檢查這些數據是否爲空、手機號是否符合規範、驗證碼是否有效、密碼有沒有包含了特殊字符等。正確姿式就是當全部檢查都經過了以後，才調用API接口。最後，調用註冊接口成功後，可能還要再調用一次登陸接口，並可能將用戶登陸信息緩存起來，方便用戶下次啓動應用時自動登陸。全部這些都屬於業務邏輯處理，也就是業務層的工做。

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

所以，簡單點說，業務層就是處理業務邏輯，包括數據的檢查、業務分支的處理等。好比上面第二個例子，可能不少人就會將用戶是否已經登陸的判斷直接在界面上作處理，當確認登陸後，token也是有效的以後，才調用業務層作購買商品的操做，這就是致使業務層淪落爲API的數據中轉站的直接表現。

業務層的交互

只有真正理解了業務層的職責以後，纔能有效地設計業務層與外層的交互接口。

業務層向下，與數據層交互；向上，與展現層交互。

與數據層交互只是調用數據層的接口獲取數據，而與展現層交互則須要提供接口給展現層調用。由於業務處理通常屬於比較耗時的操做，主要在於底層的網絡請求比較耗時，因此提供給展現層的接口數據結果應該以異步的方式提供，所以，接口上就須要提供個回調參數，返回業務處理以後的結果。我以前分享過的Android項目重構之路:實現篇有講到一種實現方式，可參考。

寫在最後

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

問啊-定製化IT教育平臺，牛人一對一服務，有問必答，開發編程社交頭條 官方網站：www.wenaaa.com 下載問啊APP，參與官方懸賞，賺百元現金。

QQ羣290551701 彙集不少互聯網精英，技術總監，架構師，項目經理！開源技術研究，歡迎業內人士，大牛及新手有志於從事IT行業人員進入！