App架構設計經驗談:業務層的設計
業務層其實并不復雜,但是大部分開發人員對其職責并沒有理解清楚,從而使其淪落為一個數據中轉站。我之前分享過的Android項目重構之路系列中提到的核心層,其實就是這里所講的業務層。但有不少讀者反映,他們在實際項目中就只是做一下參數檢查,然后直接調用API,與展示層對接的接口基本也與API的接口一致的。這樣,業務層無疑就已經變為了一個數據中轉站。
業務層的職責
所以,設計業務層之前,對業務層的職責要先真正理解清楚。這里,我舉兩個栗子說明一下。
第一個是新用戶注冊的例子。注冊時,界面上一般都會要求用戶輸入手機號、驗證碼、密碼和確認密碼。但是,API接口一般只會有三個參數:手機號、驗證碼和密碼,不會有確認密碼。因此,調用接口之前,密碼和確認密碼的一致性檢查是必須的。同時,也要檢查這些數據是否為空、手機號是否符合規范、驗證碼是否有效、密碼有沒有包含了特殊字符等。正確姿勢就是當所有檢查都通過了之后,才調用API接口。最后,調用注冊接口成功后,可能還要再調用一次登錄接口,并可能將用戶登錄信息緩存起來,方便用戶下次啟動應用時自動登錄。所有這些都屬于業務邏輯處理,也就是業務層的工作。
第二個是涉及用戶驗證的例子。比如,在一個電商App,當用戶瀏覽某個商品,點擊購買時,App首先會判斷用戶是否已經登錄,如未登錄,則會跳轉到登錄頁面讓用戶先登錄。如果已經登錄,但token已經過期,那需要先去獲取新的token,之后才能進行下一步的購物操作。這些邏輯處理,也是業務層的工作。
因此,簡單點說,業務層就是處理業務邏輯,包括數據的檢查、業務分支的處理等。比如上面第二個例子,可能很多人就會將用戶是否已經登錄的判斷直接在界面上做處理,當確認登錄后,token也是有效的之后,才調用業務層做購買商品的操作,這就是導致業務層淪落為API的數據中轉站的直接表現。
業務層的交互
只有真正理解了業務層的職責之后,才能有效地設計業務層與外層的交互接口。
業務層向下,與數據層交互;向上,與展示層交互。
與數據層交互只是調用數據層的接口獲取數據,而與展示層交互則需要提供接口給展示層調用。因為業務處理一般屬于比較耗時的操作,主要在于底層的網絡請求比較耗時,所以提供給展示層的接口數據結果應該以異步的方式提供,因此,接口上就需要提供個回調參數,返回業務處理之后的結果。我之前分享過的Android項目重構之路:實現篇有講到一種實現方式,可參考。
寫在最后
業務層可以說是一個數據加工場,處理核心的業務邏輯。其實,只要理解清楚了業務層的職責,業務層就不難實現。
來源@Keegan小鋼(微信公眾號:keeganlee_me)
?
這是基本常識好么,