相關(guān)閱讀：杭州程序員從互聯(lián)網(wǎng)跳央企，曬一天工作和收入，網(wǎng)友：待一年就廢

來源：https://www.cnblogs.com/bainannan/p/14418277.html

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)用遠程服務(wù)，這樣就導(dǎo)致了每個人的開發(fā)代碼風(fēng)格完全不同。

后續(xù)其他人修改的時候，一看，我靠這個人寫的代碼和我平常的習(xí)慣完全不同，修改的時候到底是按著自己以前的習(xí)慣改，還是跟著前輩們走，這又是個艱難的選擇，選擇一旦有偏差，你的后輩又維護你的代碼的時候，恐怕就要罵人了。

所以一個好的應(yīng)用分層需要具備以下幾點:

• 方便后續(xù)代碼進行維護擴展。

• 分層的效果需要讓整個團隊都接受

• 各個層職責(zé)邊界清晰

2.如何進行分層

2.1阿里規(guī)范

在阿里的編碼規(guī)范中約束的分層如下:

開放接口層: 可直接封裝 Service 方法暴露成 RPC 接口;通過 Web 封裝成 http 接口;進行 網(wǎng)關(guān)安全控制、流量控制等。搜索公眾號互聯(lián)網(wǎng)架構(gòu)師復(fù)“2T”，送你一份驚喜禮包。

終端顯示層: 各個端的模板渲染并執(zhí)行顯示的層。當(dāng)前主要是 velocity 渲染，JS 渲染， JSP 渲染，移動端展示等。

Web 層: 主要是對訪問控制進行轉(zhuǎn)發(fā)，各類基本參數(shù)校驗，或者不復(fù)用的業(yè)務(wù)簡單處理等。

Service 層: 相對具體的業(yè)務(wù)邏輯服務(wù)層。

Manager 層: 通用業(yè)務(wù)處理層，它有如下特征:1. 對第三方平臺封裝的層，預(yù)處理返回結(jié)果及轉(zhuǎn)化異常信息;2. 對Service層通用能力的下沉，如緩存方案、中間件通用處理;3. 與DAO層交互，對多個DAO的組合復(fù)用。

DAO 層: 數(shù)據(jù)訪問層，與底層 MySQL、Oracle、Hbase 進行數(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層類似搜索公眾號互聯(lián)網(wǎng)架構(gòu)師復(fù)“2T”，送你一份驚喜禮包。

1.最上層controller和TService是我們阿里分層規(guī)范里面的第一層: 輕業(yè)務(wù)邏輯，參數(shù)校驗，異常兜底。通常這種接口可以輕易更換接口類型,所以業(yè)務(wù)邏輯必須要輕，甚至不做具體邏輯。

2.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ù)編排邏輯都得放進service中去做:搜索公眾號互聯(lián)網(wǎng)架構(gòu)師復(fù)“2T”，送你一份驚喜禮包。

3.Mannager：可復(fù)用邏輯層。這里的Mannager可以是單個服務(wù)的，比如我們的cache,mq等等，當(dāng)然也可以是復(fù)合的，當(dāng)你需要調(diào)用多個Mannager的時候，這個可以合為一個Mannager，比如邏輯上的連表查詢等。如果是httpMannager或rpcMannager需要在這一層做一些數(shù)據(jù)轉(zhuǎn)換

4.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ī)約:

• DO（Data Object）：與數(shù)據(jù)庫表結(jié)構(gòu)一一對應(yīng)，通過DAO層向上傳輸數(shù)據(jù)源對象。
• DTO（Data Transfer Object）：數(shù)據(jù)傳輸對象，Service或Manager向外傳輸?shù)膶ο蟆?/span>
• BO（Business Object）：業(yè)務(wù)對象。由Service層輸出的封裝業(yè)務(wù)邏輯的對象。
• AO（Application Object）：應(yīng)用對象。在Web層與Service層之間抽象的復(fù)用對象模型，極為貼近展示層，復(fù)用度不高。
• VO（View Object）：顯示層對象，通常是Web向模板渲染引擎層傳輸?shù)膶ο蟆?/span>
• Query：數(shù)據(jù)查詢對象，各層接收上層的查詢請求。注意超過2個參數(shù)的查詢封裝，禁止使用Map類來傳輸。

每一個層基本都自己對應(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ù)維護容易，就是好的分層。

1、985副教授工資曝光
2、心態(tài)崩了！稅前2萬4，到手1萬4，年終獎扣稅方式1月1日起施行~
3、雷軍做程序員時寫的博客，很強大！
4、人臉識別的時候，一定要穿上衣服??！
5、清華大學(xué)：2021 元宇宙研究報告！
6、績效被打3.25B，員工將支付寶告上了法院，判了