2021-02-06 分類: 網(wǎng)站建設(shè)
Java知音出品
1、背景
說起應(yīng)用分層,大部分人都會認(rèn)為這個不是很簡單嘛 就controller,service, mapper三層。看起來簡單,很多人其實并沒有把他們職責(zé)劃分開,在很多代碼中,controller做的邏輯比service還多,service往往當(dāng)成透傳了,這其實是很多人開發(fā)代碼都沒有注意到的地方,反正功能也能用,至于放哪無所謂唄。這樣往往造成后面代碼無法復(fù)用,層級關(guān)系混亂,對后續(xù)代碼的維護非常麻煩。
的確在這些人眼中分層只是一個形式,前輩們的代碼這么寫的,其他項目代碼這么寫的,那么我也這么跟著寫。但是在真正的團隊開發(fā)中每個人的習(xí)慣都不同,寫出來的代碼必然帶著自己的標(biāo)簽,有的人習(xí)慣controller寫大量的業(yè)務(wù)邏輯,有的人習(xí)慣在service中之間調(diào)用遠(yuǎn)程服務(wù),這樣就導(dǎo)致了每個人的開發(fā)代碼風(fēng)格完全不同,后續(xù)其他人修改的時候,一看,我靠這個人寫的代碼和我平常的習(xí)慣完全不同,修改的時候到底是按著自己以前的習(xí)慣改,還是跟著前輩們走,這又是個艱難的選擇,選擇一旦有偏差,你的后輩又維護你的代碼的時候,恐怕就要罵人了。
所以一個好的應(yīng)用分層需要具備以下幾點:
2、如何進(jìn)行分層
2.1、阿里規(guī)范
在阿里的編碼規(guī)范中約束的分層如下:
開放接口層:可直接封裝 Service 方法暴露成 RPC 接口;通過 Web 封裝成 http 接口;進(jìn)行 網(wǎng)關(guān)安全控制、流量控制等。
終端顯示層:各個端的模板渲染并執(zhí)行顯示的層。當(dāng)前主要是 velocity 渲染,JS 渲染, JSP 渲染,移動端展示等。
Web 層:主要是對訪問控制進(jìn)行轉(zhuǎn)發(fā),各類基本參數(shù)校驗,或者不復(fù)用的業(yè)務(wù)簡單處理等。
Service 層:相對具體的業(yè)務(wù)邏輯服務(wù)層。
Manager 層:通用業(yè)務(wù)處理層,它有如下特征:
DAO 層:數(shù)據(jù)訪問層,與底層 MySQL、Oracle、Hbase 進(jìn)行數(shù)據(jù)交互。
阿里巴巴規(guī)約中的分層比較清晰簡單明了,但是描述得還是過于簡單了,以及service層和manager層有很多同學(xué)還是有點分不清楚之間的關(guān)系,就導(dǎo)致了很多項目中根本沒有Manager層的存在。下面介紹一下具體業(yè)務(wù)中應(yīng)該如何實現(xiàn)分層。
2.2、優(yōu)化分層
從我們的業(yè)務(wù)開發(fā)中總結(jié)了一個較為的理想模型,這里要先說明一下由于我們的rpc框架選用的是thrift可能會比其他的一些rpc框架例如dubbo會多出一層,作用和controller層類似:
最上層controller和TService是阿里分層規(guī)范里面的第一層:輕業(yè)務(wù)邏輯,參數(shù)校驗,異常兜底。通常這種接口可以輕易更換接口類型,所以業(yè)務(wù)邏輯必須要輕,甚至不做具體邏輯。
Service:業(yè)務(wù)層,復(fù)用性較低,這里推薦每一個controller方法都得對應(yīng)一個service,不要把業(yè)務(wù)編排放在controller中去做,為什么呢?如果我們把業(yè)務(wù)編排放在controller層去做的話,如果以后我們要接入thrift,我們這里又需要把業(yè)務(wù)編排在做一次,這樣會導(dǎo)致我們每接入一個入口層這個代碼都得重新復(fù)制一份如下圖所示:
這樣大量的重復(fù)工作必定會導(dǎo)致我們開發(fā)效率下降,所以我們需要把業(yè)務(wù)編排邏輯都得放進(jìn)service中去做:
Mannager:可復(fù)用邏輯層。這里的Mannager可以是單個服務(wù)的,比如我們的cache,mq等等,當(dāng)然也可以是復(fù)合的,當(dāng)你需要調(diào)用多個Mannager的時候,這個可以合為一個Mannager,比如邏輯上的連表查詢等。如果是httpMannager或rpcMannager需要在這一層做一些數(shù)據(jù)轉(zhuǎn)換
DAO:數(shù)據(jù)庫訪問層。主要負(fù)責(zé)“操作數(shù)據(jù)庫的某張表,映射到某個java對象”,dao應(yīng)該只允許自己的Service訪問,其他Service要訪問我的數(shù)據(jù)必須通過對應(yīng)的Service。
3、分層領(lǐng)域模型的轉(zhuǎn)換
在阿里巴巴編碼規(guī)約中列舉了下面幾個領(lǐng)域模型規(guī)約:
每一個層基本都自己對應(yīng)的領(lǐng)域模型,這樣就導(dǎo)致了有些人過于追求每一層都是用自己的領(lǐng)域模型,這樣就導(dǎo)致了一個對象可能會出現(xiàn)3次甚至4次轉(zhuǎn)換在一次請求中,當(dāng)返回的時候同樣也會出現(xiàn)3-4次轉(zhuǎn)換,這樣有可能一次完整的請求-返回會出現(xiàn)很多次對象轉(zhuǎn)換。如果在開發(fā)中真的按照這么來,恐怕就別寫其他的了,一天就光寫這個重復(fù)無用的邏輯算了吧。
所以我們得采取一個折中的方案:
1、允許Service/Manager可以操作數(shù)據(jù)領(lǐng)域模型,對于這個層級來說,本來自己做的工作也是做的是業(yè)務(wù)邏輯處理和數(shù)據(jù)組裝。
2、Controller/TService層的領(lǐng)域模型不允許傳入DAO層,這樣就不符合職責(zé)劃分了。
3、同理,不允許DAO層的數(shù)據(jù)傳入到Controller/TService。
4、總結(jié)
總的來說業(yè)務(wù)分層對于代碼規(guī)范是比較重要,決定著以后的代碼是否可復(fù)用,是否職責(zé)清晰,邊界清晰。
當(dāng)然這種分層其實見仁見智, 團隊中的所有人的分層習(xí)慣也不同,所以很難權(quán)衡出一個標(biāo)準(zhǔn)的準(zhǔn)則,總的來說只要滿足職責(zé)邏輯清晰,后續(xù)維護容易,就是好的分層。
最后,如果你的團隊有更好的分層,或者上面所描述的有什么錯誤的地方還請留言指正一下。
本文題目:你知道優(yōu)秀的代碼都是怎么樣去分層的嗎?
路徑分享:http://m.newbst.com/news10/99510.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站導(dǎo)航、網(wǎng)站設(shè)計、定制開發(fā)、網(wǎng)站內(nèi)鏈、定制網(wǎng)站、做網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容