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

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