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