背景
說(shuō)起應(yīng)用分層，大部分人都會(huì)認(rèn)為這個(gè)不是很簡(jiǎn)單嘛，就 Controller，Service，Mapper 三層?？雌饋?lái)簡(jiǎn)單，很多人其實(shí)并沒(méi)有把他們職責(zé)劃分開(kāi)，在很多代碼中，Controller 做的邏輯比 Service 還多，Service 往往當(dāng)成透?jìng)髁?，這其實(shí)是很多人開(kāi)發(fā)代碼都沒(méi)有注意到的地方，反正功能也能用，至于放哪無(wú)所謂唄。這樣往往造成后面代碼無(wú)法復(fù)用，層級(jí)關(guān)系混亂，對(duì)后續(xù)代碼的維護(hù)非常麻煩。
的確在這些人眼中分層只是一個(gè)形式，前輩們的代碼這么寫(xiě)的，其他項(xiàng)目代碼這么寫(xiě)的，那么我也這么跟著寫(xiě)。
但是在真正的團(tuán)隊(duì)開(kāi)發(fā)中每個(gè)人的習(xí)慣都不同，寫(xiě)出來(lái)的代碼必然帶著自己的標(biāo)簽，有的人習(xí)慣 Controller 寫(xiě)大量的業(yè)務(wù)邏輯，有的人習(xí)慣在 Service 中之間調(diào)用遠(yuǎn)程服務(wù)。
這樣就導(dǎo)致了每個(gè)人的開(kāi)發(fā)代碼風(fēng)格完全不同，后續(xù)其他人修改的時(shí)候，一看，我靠這個(gè)人寫(xiě)的代碼和我平常的習(xí)慣完全不同，修改的時(shí)候到底是按著自己以前的習(xí)慣改，還是跟著前輩們走。
這又是個(gè)艱難的選擇，選擇一旦有偏差，你的后輩又維護(hù)你的代碼的時(shí)候，恐怕就要罵人了。
所以一個(gè)好的應(yīng)用分層需要具備以下幾點(diǎn)：
- 方便后續(xù)代碼進(jìn)行維護(hù)擴(kuò)展
- 分層的效果需要讓整個(gè)團(tuán)隊(duì)都接受
- 各個(gè)層職責(zé)邊界清晰
如何進(jìn)行分層
阿里規(guī)范
在阿里的編碼規(guī)范中約束的分層如下圖：
①開(kāi)放接口層：可直接封裝 Service 方法暴露成 RPC 接口；通過(guò) Web 封裝成 http 接口；進(jìn)行網(wǎng)關(guān)安全控制、流量控制等。
②終端顯示層：各個(gè)端的模板渲染并執(zhí)行顯示的層。當(dāng)前主要是 velocity 渲染，JS 渲染，JSP 渲染，移動(dòng)端展示等。
③Web 層：主要是對(duì)訪問(wèn)控制進(jìn)行轉(zhuǎn)發(fā)，各類(lèi)基本參數(shù)校驗(yàn)，或者不復(fù)用的業(yè)務(wù)簡(jiǎn)單處理等。
④Service 層：相對(duì)具體的業(yè)務(wù)邏輯服務(wù)層。
⑤Manager 層：通用業(yè)務(wù)處理層。
它有如下特征:
- 對(duì)第三方平臺(tái)封裝的層，預(yù)處理返回結(jié)果及轉(zhuǎn)化異常信息。
- 對(duì) Service 層通用能力的下沉，如緩存方案、中間件通用處理。
- 與 DAO 層交互，對(duì)多個(gè) DAO 的組合復(fù)用。
⑥D(zhuǎn)AO 層：數(shù)據(jù)訪問(wèn)層，與底層 MySQL、Oracle、Hbase 進(jìn)行數(shù)據(jù)交互。
阿里巴巴規(guī)約中的分層比較清晰簡(jiǎn)單明了，但是描述得還是過(guò)于簡(jiǎn)單了，以及 Service 層和 Manager 層有很多同學(xué)還是有點(diǎn)分不清楚之間的關(guān)系，就導(dǎo)致了很多項(xiàng)目中根本沒(méi)有 Manager 層的存在。
下面介紹一下具體業(yè)務(wù)中應(yīng)該如何實(shí)現(xiàn)分層。
優(yōu)化分層
從我們的業(yè)務(wù)開(kāi)發(fā)中總結(jié)了一個(gè)較為的理想模型,這里要先說(shuō)明一下由于我們的 RPC 框架選用的是 Thrift 可能會(huì)比其他的一些 RPC 框架例如 Dubbo 會(huì)多出一層，作用和 controller 層類(lèi)似。
最上層 Controller 和 TService 是我們阿里分層規(guī)范里面的第一層：輕業(yè)務(wù)邏輯，參數(shù)校驗(yàn)，異常兜底。
通常這種接口可以輕易更換接口類(lèi)型，所以業(yè)務(wù)邏輯必須要輕，甚至不做具體邏輯。
①Service：業(yè)務(wù)層，復(fù)用性較低，這里推薦每一個(gè) Controller 方法都得對(duì)應(yīng)一個(gè) Service，不要把業(yè)務(wù)編排放在 Controller 中去做，為什么呢？
如果我們把業(yè)務(wù)編排放在 Controller 層去做的話(huà)，如果以后我們要接入 Thrift，我們這里又需要把業(yè)務(wù)編排在做一次，這樣會(huì)導(dǎo)致我們每接入一個(gè)入口層這個(gè)代碼都得重新復(fù)制一份。
如下圖所示：
這樣大量的重復(fù)工作必定會(huì)導(dǎo)致我們開(kāi)發(fā)效率下降，所以我們需要把業(yè)務(wù)編排邏輯都得放進(jìn) Service 中去做：
②Mannager：可復(fù)用邏輯層。這里的 Mannager 可以是單個(gè)服務(wù)的，比如我們的 Cache，MQ 等等，當(dāng)然也可以是復(fù)合的。
當(dāng)你需要調(diào)用多個(gè) Mannager 的時(shí)候，這個(gè)可以合為一個(gè) Mannager，比如邏輯上的連表查詢(xún)等。如果是 httpMannager 或 rpcMannager 需要在這一層做一些數(shù)據(jù)轉(zhuǎn)換。
③DAO：數(shù)據(jù)庫(kù)訪問(wèn)層。主要負(fù)責(zé)“操作數(shù)據(jù)庫(kù)的某張表，映射到某個(gè) Java 對(duì)象”，DAO 應(yīng)該只允許自己的 Service 訪問(wèn)，其他 Service 要訪問(wèn)我的數(shù)據(jù)必須通過(guò)對(duì)應(yīng)的 Service。
分層領(lǐng)域模型的轉(zhuǎn)換
在阿里巴巴編碼規(guī)約中列舉了下面幾個(gè)領(lǐng)域模型規(guī)約：
- DO（Data Object）：與數(shù)據(jù)庫(kù)表結(jié)構(gòu)一一對(duì)應(yīng)，通過(guò) DAO 層向上傳輸數(shù)據(jù)源對(duì)象。
- DTO（Data Transfer Object）：數(shù)據(jù)傳輸對(duì)象，Service 或 Manager 向外傳輸?shù)膶?duì)象。
- BO（Business Object）：業(yè)務(wù)對(duì)象。由 Service 層輸出的封裝業(yè)務(wù)邏輯的對(duì)象。
- AO（Application Object）：應(yīng)用對(duì)象。在 Web 層與 Service 層之間抽象的復(fù)用對(duì)象模型，極為貼近展示層，復(fù)用度不高。
- VO（View Object）：顯示層對(duì)象，通常是 Web 向模板渲染引擎層傳輸?shù)膶?duì)象。
- Query：數(shù)據(jù)查詢(xún)對(duì)象，各層接收上層的查詢(xún)請(qǐng)求。注意超過(guò)2個(gè)參數(shù)的查詢(xún)封裝，禁止使用 Map 類(lèi)來(lái)傳輸。
| 層次 | 領(lǐng)域模型 |
|---|---|
| Controller/TService | VO/DTO |
| Service/Manager | AO/BO |
| DAO | DO |
每一個(gè)層基本都自己對(duì)應(yīng)的領(lǐng)域模型，這樣就導(dǎo)致了有些人過(guò)于追求每一層都是用自己的領(lǐng)域模型。
這樣就導(dǎo)致了一個(gè)對(duì)象可能會(huì)出現(xiàn) 3 次甚至 4 次轉(zhuǎn)換在一次請(qǐng)求中，當(dāng)返回的時(shí)候同樣也會(huì)出現(xiàn) 3-4 次轉(zhuǎn)換，這樣有可能一次完整的請(qǐng)求-返回會(huì)出現(xiàn)很多次對(duì)象轉(zhuǎn)換。
如果在開(kāi)發(fā)中真的按照這么來(lái)，恐怕就別寫(xiě)其他的了，一天就光寫(xiě)這個(gè)重復(fù)無(wú)用的邏輯算了吧。
所以我們得采取一個(gè)折中的方案：
- 允許 Service/Manager 可以操作數(shù)據(jù)領(lǐng)域模型，對(duì)于這個(gè)層級(jí)來(lái)說(shuō)，本來(lái)自己做的工作也是做的是業(yè)務(wù)邏輯處理和數(shù)據(jù)組裝。
- Controller/TService 層的領(lǐng)域模型不允許傳入 DAO 層，這樣就不符合職責(zé)劃分了。
- 同理，不允許 DAO 層的數(shù)據(jù)傳入到 Controller/TService。
總結(jié)
總的來(lái)說(shuō)業(yè)務(wù)分層對(duì)于代碼規(guī)范是比較重要，決定著以后的代碼是否可復(fù)用，是否職責(zé)清晰，邊界清晰。
當(dāng)然這種分層其實(shí)見(jiàn)仁見(jiàn)智，團(tuán)隊(duì)中的所有人的分層習(xí)慣也不同，所以很難權(quán)衡出一個(gè)標(biāo)準(zhǔn)的準(zhǔn)則，總的來(lái)說(shuō)只要滿(mǎn)足職責(zé)邏輯清晰，后續(xù)維護(hù)容易，就是好的分層。
到此這篇關(guān)于 Java 項(xiàng)目中如何正確分層的全部?jī)?nèi)容就介紹到這了,想要了解更多相關(guān) Java 項(xiàng)目分層的其他內(nèi)容請(qǐng)搜索W3Cschool以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持我們！
