關(guān)于APP架構(gòu)規(guī)劃——事務層的規(guī)劃

　　事務層其實并不雜亂，可是大部分開發(fā)人員對其責任并沒有了解清楚，從而使其流浪為一個數(shù)據(jù)中轉(zhuǎn)站。
　　事務層的責任
　　所以，規(guī)劃事務層之前，對事務層的責任要先真實了解清楚。這兒，浪訊舉兩個栗子闡明一下。
　　第一個是新用戶注冊的比方。注冊時，界面上一般都會要求用戶輸入手機號、驗證碼、暗碼和承認暗碼�？墒�，API接口一般只會有三個參數(shù)：手機號、驗證碼和暗碼，不會有承認暗碼。因而，調(diào)用接口之前，暗碼和承認暗碼的一致性查看是有必要的。同時，也要查看這些數(shù)據(jù)是否為空、手機號是否符合標準、驗證碼是否有用、暗碼有沒有包含了特別字符等。正確姿態(tài)便是當一切查看都通過了之后，才調(diào)用API接口。最終，調(diào)用注冊接口成功后，或許還要再調(diào)用一次登錄接口，并或許將用戶登錄信息緩存起來，方便用戶下次發(fā)動應用時自動登錄。一切這些都歸于事務邏輯處理，也便是事務層的工作。
　　第二個是觸及用戶驗證的比方。比方，在一個電商App，當用戶閱讀某個產(chǎn)品，點擊購買時，App首先會判斷用戶是否現(xiàn)已登錄，如未登錄，則會跳轉(zhuǎn)到登錄頁面讓用戶先登錄。如果現(xiàn)已登錄，但token現(xiàn)已過期，那需求先去獲取新的token，之后才干進行下一步的購物操作。這些邏輯處理，也是事務層的工作。
　　因而，簡單點說，事務層便是處理事務邏輯，包含數(shù)據(jù)的查看、事務分支的處理等。比方上面第二個比方，或許很多人就會將用戶是否現(xiàn)已登錄的判斷直接在界面上做處理，當承認登錄后，token也是有用的之后，才調(diào)用事務層做購買產(chǎn)品的操作，這便是導致事務層流浪為API的數(shù)據(jù)中轉(zhuǎn)站的直接表現(xiàn)。
　　事務層的交互
　　只要真實了解了事務層的責任之后，才干有用地規(guī)劃事務層與外層的交互接口。
　　事務層向下，與數(shù)據(jù)層交互;向上，與展現(xiàn)層交互。
　　與數(shù)據(jù)層交互只是調(diào)用數(shù)據(jù)層的接口獲取數(shù)據(jù)，而與展現(xiàn)層交互則需求供給接口給展現(xiàn)層調(diào)用。由于事務處理一般歸于比較耗時的操作，主要在于底層的網(wǎng)絡(luò)懇求比較耗時，所以供給給展現(xiàn)層的接口數(shù)據(jù)結(jié)果應該以異步的方式供給，因而，接口上就需求供給個回調(diào)參數(shù)，回來事務處理之后的結(jié)果。
　　事務層可以說是一個數(shù)據(jù)加工場，處理中心的事務邏輯。其實，只要了解清楚了事務層的責任，事務層就不難完成。