App下載

教你怎么在Java項目中正確的分層

猿友 2021-07-22 10:57:28 瀏覽數(shù) (3808)
反饋

背景

說起應用分層,大部分人都會認為這個不是很簡單嘛,就 Controller,Service,Mapper 三層。看起來簡單,很多人其實并沒有把他們職責劃分開,在很多代碼中,Controller 做的邏輯比 Service 還多,Service 往往當成透傳了,這其實是很多人開發(fā)代碼都沒有注意到的地方,反正功能也能用,至于放哪無所謂唄。這樣往往造成后面代碼無法復用,層級關系混亂,對后續(xù)代碼的維護非常麻煩。

的確在這些人眼中分層只是一個形式,前輩們的代碼這么寫的,其他項目代碼這么寫的,那么我也這么跟著寫。

但是在真正的團隊開發(fā)中每個人的習慣都不同,寫出來的代碼必然帶著自己的標簽,有的人習慣 Controller 寫大量的業(yè)務邏輯,有的人習慣在 Service 中之間調(diào)用遠程服務。

這樣就導致了每個人的開發(fā)代碼風格完全不同,后續(xù)其他人修改的時候,一看,我靠這個人寫的代碼和我平常的習慣完全不同,修改的時候到底是按著自己以前的習慣改,還是跟著前輩們走。

這又是個艱難的選擇,選擇一旦有偏差,你的后輩又維護你的代碼的時候,恐怕就要罵人了。

所以一個好的應用分層需要具備以下幾點:

  • 方便后續(xù)代碼進行維護擴展
  • 分層的效果需要讓整個團隊都接受
  • 各個層職責邊界清晰

如何進行分層

阿里規(guī)范

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

①開放接口層:可直接封裝 Service 方法暴露成 RPC 接口;通過 Web 封裝成 http 接口;進行網(wǎng)關安全控制、流量控制等。

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

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

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

⑤Manager 層:通用業(yè)務處理層。

它有如下特征:

  • 對第三方平臺封裝的層,預處理返回結果及轉化異常信息。
  • 對 Service 層通用能力的下沉,如緩存方案、中間件通用處理。
  • 與 DAO 層交互,對多個 DAO 的組合復用。

⑥DAO 層:數(shù)據(jù)訪問層,與底層 MySQL、Oracle、Hbase 進行數(shù)據(jù)交互。

阿里巴巴規(guī)約中的分層比較清晰簡單明了,但是描述得還是過于簡單了,以及 Service 層和 Manager 層有很多同學還是有點分不清楚之間的關系,就導致了很多項目中根本沒有 Manager 層的存在。

下面介紹一下具體業(yè)務中應該如何實現(xiàn)分層。

優(yōu)化分層

從我們的業(yè)務開發(fā)中總結了一個較為的理想模型,這里要先說明一下由于我們的 RPC 框架選用的是 Thrift 可能會比其他的一些 RPC 框架例如 Dubbo 會多出一層,作用和 controller 層類似。

最上層 Controller 和 TService 是我們阿里分層規(guī)范里面的第一層:輕業(yè)務邏輯,參數(shù)校驗,異常兜底。

通常這種接口可以輕易更換接口類型,所以業(yè)務邏輯必須要輕,甚至不做具體邏輯。

①Service:業(yè)務層,復用性較低,這里推薦每一個 Controller 方法都得對應一個 Service,不要把業(yè)務編排放在 Controller 中去做,為什么呢?

如果我們把業(yè)務編排放在 Controller 層去做的話,如果以后我們要接入 Thrift,我們這里又需要把業(yè)務編排在做一次,這樣會導致我們每接入一個入口層這個代碼都得重新復制一份。

如下圖所示:

這樣大量的重復工作必定會導致我們開發(fā)效率下降,所以我們需要把業(yè)務編排邏輯都得放進 Service 中去做:

②Mannager:可復用邏輯層。這里的 Mannager 可以是單個服務的,比如我們的 Cache,MQ 等等,當然也可以是復合的。

當你需要調(diào)用多個 Mannager 的時候,這個可以合為一個 Mannager,比如邏輯上的連表查詢等。如果是 httpMannager 或 rpcMannager 需要在這一層做一些數(shù)據(jù)轉換。

③DAO:數(shù)據(jù)庫訪問層。主要負責“操作數(shù)據(jù)庫的某張表,映射到某個 Java 對象”,DAO 應該只允許自己的 Service 訪問,其他 Service 要訪問我的數(shù)據(jù)必須通過對應的 Service。

分層領域模型的轉換

在阿里巴巴編碼規(guī)約中列舉了下面幾個領域模型規(guī)約:

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

層次 領域模型
Controller/TService VO/DTO
Service/Manager AO/BO
DAO DO

每一個層基本都自己對應的領域模型,這樣就導致了有些人過于追求每一層都是用自己的領域模型。

這樣就導致了一個對象可能會出現(xiàn) 3 次甚至 4 次轉換在一次請求中,當返回的時候同樣也會出現(xiàn) 3-4 次轉換,這樣有可能一次完整的請求-返回會出現(xiàn)很多次對象轉換。

如果在開發(fā)中真的按照這么來,恐怕就別寫其他的了,一天就光寫這個重復無用的邏輯算了吧。

所以我們得采取一個折中的方案:

  • 允許 Service/Manager 可以操作數(shù)據(jù)領域模型,對于這個層級來說,本來自己做的工作也是做的是業(yè)務邏輯處理和數(shù)據(jù)組裝。
  • Controller/TService 層的領域模型不允許傳入 DAO 層,這樣就不符合職責劃分了。
  • 同理,不允許 DAO 層的數(shù)據(jù)傳入到 Controller/TService。

總結

總的來說業(yè)務分層對于代碼規(guī)范是比較重要,決定著以后的代碼是否可復用,是否職責清晰,邊界清晰。

當然這種分層其實見仁見智,團隊中的所有人的分層習慣也不同,所以很難權衡出一個標準的準則,總的來說只要滿足職責邏輯清晰,后續(xù)維護容易,就是好的分層。

到此這篇關于 Java 項目中如何正確分層的全部內(nèi)容就介紹到這了,想要了解更多相關 Java 項目分層的其他內(nèi)容請搜索W3Cschool以前的文章或繼續(xù)瀏覽下面的相關文章,希望大家以后多多支持我們!


0 人點贊