Java Web應用的程式碼分層最佳實踐。

weixin_34370347發表於2018-06-22

程式碼分層,對於任何一個Java Web開發來說應該都不陌生。一個好的層次劃分不僅可以能使程式碼結構更加清楚,還可以使專案分工更加明確,可讀性大大提升,更加有利於後期的維護和升級。

從另外一個角度來看,好的程式碼分層架構,應該是可以很好的匹配上單一職責原則的。這樣就可以降低層與層之間的依賴,還能最大程度的複用各層的邏輯。本文就來介紹下Java Web專案的程式碼到底應該如何分層。

三層架構

在軟體體系架構設計中,分層式結構是最常見,也是最重要的一種結構。微軟推薦的分層式結構一般分為三層,從下至上分別為:資料訪問層、業務邏輯層(又或稱為領域層)、表示層。這也是Java Web中重要的三層架構中的三個層次。區分層次的目的即為了“高內聚低耦合”的思想。

所謂三層體系結構,是在客戶端與資料庫之間加入了一個“中間層”,也叫元件層。這裡所說的三層體系,不是指物理上的三層,不是簡單地放置三臺機器就是三層體系結構,也不僅僅有B/S應用才是三層體系結構,三層是指邏輯上的三層,即把這三個層放置到一臺機器上。

資料訪問層

主要是對非原始資料(資料庫或者文字檔案等存放資料的形式)的操作層,而不是指原始資料,也就是說,是對資料庫的操作,而不是資料,具體為業務邏輯層或表示層提供資料服務。

業務邏輯層

主要是針對具體的問題的操作,也可以理解成對資料層的操作,對資料業務邏輯處理,如果說資料層是積木,那邏輯層就是對這些積木的搭建。

介面層

主要表示WEB方式。如果邏輯層相當強大和完善,無論表現層如何定義和更改,邏輯層都能完善地提供服務。

三層架構與MVC的區別

MVC(模型Model-檢視View-控制器Controller)是一種架構模式,可以用它來建立在域物件和UI表示層物件之間的區分。

MVC

同樣是架構級別的,相同的地方在於他們都有一個表現層,但是他們不同的地方在於其他的兩個層。

在三層架構中沒有定義Controller的概念。這是最不同的地方。而MVC也沒有把業務的邏輯訪問看成兩個層,這是採用三層架構或MVC搭建程式最主要的區別。

3

更加細緻的分層

隨著網站的使用者量的不斷提升,系統架構也在不斷的調整。有時候,隨著業務越來越複雜,有時候三層架構好像不夠用了。比如,我們的應用除了要給使用者提供頁面訪問以外,還需要提供一些開放介面,供外部系統呼叫。這個介面既不屬於介面層,也不應該屬於業務邏輯層,因為他還可能包含一些和業務邏輯無關的處理,如許可權控制、流量控制等。

還有,隨著微服務的盛行,我們應用中可能要依賴很多外部介面或第三方平臺。這部分程式碼放下業務邏輯層和資料訪問層也都不合適。

所以,漸漸的,在三層架構的基礎上,系統架構的分層變得更加複雜了。也正是因為複雜,就非常考驗架構設計能力,因為層次劃分的不好,很可能會影響後面的開發,給程式碼維護帶來很大的困難。

下圖,是阿里巴巴(參考《阿里巴巴Java開發手冊》)提倡的應用分層結構:

ceng

開放介面層

可直接封裝 Service 方法暴露成 RPC 介面;通過 Web 封裝成 http 介面;進行閘道器安全控制、流量控制等。

終端顯示層

各個端的模板渲染並執行顯示的層。當前主要是 velocity 渲染,JS 渲染,JSP 渲染,移動端展示等。

Web 層

主要是對訪問控制進行轉發,各類基本引數校驗,或者不復用的業務簡單處理等。

Service 層

相對具體的業務邏輯服務層。

Manager 層

通用業務處理層,它有如下特徵: 1) 對第三方平臺封裝的層,預處理返回結果及轉化異常資訊; 2) 對 Service 層通用能力的下沉,如快取方案、中介軟體通用處理; 3) 與 DAO 層互動,對多個 DAO 的組合複用。

DAO 層

資料訪問層,與底層 MySQL、Oracle、Hbase 等進行資料互動。

外部介面或第三方平臺

包括其它部門 RPC 開放介面,基礎平臺,其它公司的 HTTP 介面。

事務處理

在瞭解了分層之後,我們再來看一下寫Java Web程式碼的時候,大家比較關心的一個問題,那就是涉及到資料庫操作的時候,事務處理應該在哪一層控制呢?

關於這個問題,仁者見仁,智者見智。作者認為,事務處理應該放在Service層和Manager層。

DAO層不應該有事務,應該只是很純的 CRUD 等比較通用的資料訪問方法。一個DAO應該只處理和自己相關的操作,不要有任何組合。組合的事情交給上層。

Service層和Manager層一般會組合多個DAO的CRUD操作,例如:在註冊一個使用者的時候需要往日誌表裡 INSERT 日誌,那麼就在 Service 層構造事務,在該事務中呼叫 Dao 層的 User.Insert () 與 Log.Insert ()。

異常處理

異常處理是Java中比較重要的一個話題,在《Effective Java》中有很多關於異常處理的最佳實踐,這裡不詳細介紹了,本文主要簡單說一下在應用程式碼分層之後,各個層次之間的異常應該如何處理,是自己捕獲,還是向上一層丟擲。

首先,每一層都是可能發生異常的。由於每一層的職責都不通,處理方式也可能有差別。

DAO層

在 DAO 層,產生的異常型別可能有很多,可能是SQL相關的異常,也可能是資料庫連線相關的異常。

這一層的處理方式可以簡單一點,直接try-catch(Exception),然後封裝成DAOException拋給上一層。這一層一般不需要列印日誌,交給Service或者Manager層來列印。

try{
    CRUD
}catch(Exception e){
    throw new DAOException(e);
}
複製程式碼

Manager/Service

首先,對於DAO層拋上來的異常一定要捕獲的,並且記錄日誌列印現場。

但是值得注意的是,如果是需要事務控制的方法,要注意捕獲到異常之後再向上拋一個新的異常,如 TransactionRolledbackException,否則事務無法回滾。

這兩層發生的異常可以根據情況決定是繼續向上拋還是自己處理掉。如果是自己可以處理的異常,就捕獲,打日誌,然後通過ErrorCode等方式返回給上一層。如果是自己無法處理或者不知道該如何處理的異常,就直接拋給上一層來處理。

Web

首先,可以明確的一點:Web層不應該再往外拋異常,因為這一層一旦拋異常,就可能會導致使用者跳轉到不友好的錯誤頁面甚至看到錯誤資訊等。

如果意識到這個異常將導致頁面無法正常渲染,那麼就應該直接跳轉到友好錯誤頁面,加上使用者容易理解的錯誤提示資訊。

開放介面層

這一層和Web層一樣,不可以丟擲異常。一般通過ErrorCode和ErrorMessage反饋給外部呼叫方。

這一層,要自己處理好所有的異常,定義好ErrorCode,並記錄好日誌,便於日後排查問題。

總結

本文主要介紹了Java Web專案中程式碼分層的方案,通過分層之後可以使沒一層更加專注,解除耦合。並簡單介紹了一下分層之後的事務處理和異常處理的邏輯。

Java Web應用的程式碼分層最佳實踐。

相關文章