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