程式碼分層，對於任何一個Java Web開發來說應該都不陌生。一個好的層次劃分不僅可以能使程式碼結構更加清楚，還可以使專案分工更加明確，可讀性大大提升，更加有利於後期的維護和升級。
從另外一個角度來看，好的程式碼分層架構，應該是可以很好的匹配上單一職責原則的。這樣就可以降低層與層之間的依賴，還能最大程度的複用各層的邏輯。本文就來介紹下Java Web專案的程式碼到底應該如何分層。
三層架構
在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分別為：資料訪問層、業務邏輯層（又或稱為領域層）、表示層。這也是Java Web中重要的三層架構中的三個層次。區分層次的目的即為了“高內聚低耦合”的思想。
所謂三層體系結構，是在客戶端與資料庫之間加入了一個“中間層”，也叫元件層。這裡所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是三層體系結構，也不僅僅有B/S應用才是三層體系結構，三層是指邏輯上的三層，即把這三個層放置到一臺機器上。
資料訪問層
主要是對非原始資料（資料庫或者文字檔案等存放資料的形式）的操作層，而不是指原始資料，也就是說，是對資料庫的操作，而不是資料，具體為業務邏輯層或表示層提供資料服務。
業務邏輯層
主要是針對具體的問題的操作，也可以理解成對資料層的操作，對資料業務邏輯處理，如果說資料層是積木，那邏輯層就是對這些積木的搭建。
介面層
主要表示WEB方式。如果邏輯層相當強大和完善，無論表現層如何定義和更改，邏輯層都能完善地提供服務。
三層架構與MVC的區別
MVC（模型Model-檢視View-控制器Controller）是一種架構模式，可以用它來建立在域物件和UI表示層物件之間的區分。
同樣是架構級別的，相同的地方在於他們都有一個表現層，但是他們不同的地方在於其他的兩個層。
在三層架構中沒有定義Controller的概念。這是最不同的地方。而MVC也沒有把業務的邏輯訪問看成兩個層，這是採用三層架構或MVC搭建程式最主要的區別。
更加細緻的分層
隨著網站的使用者量的不斷提升，系統架構也在不斷的調整。有時候，隨著業務越來越複雜，有時候三層架構好像不夠用了。比如，我們的應用除了要給使用者提供頁面訪問以外，還需要提供一些開放介面，供外部系統呼叫。這個介面既不屬於介面層，也不應該屬於業務邏輯層，因為他還可能包含一些和業務邏輯無關的處理，如許可權控制、流量控制等。
還有，隨著微服務的盛行，我們應用中可能要依賴很多外部介面或第三方平臺。這部分程式碼放下業務邏輯層和資料訪問層也都不合適。
所以，漸漸的，在三層架構的基礎上，系統架構的分層變得更加複雜了。也正是因為複雜，就非常考驗架構設計能力，因為層次劃分的不好，很可能會影響後面的開發，給程式碼維護帶來很大的困難。
下圖，是阿里巴巴(參考《阿里巴巴Java開發手冊》)提倡的應用分層結構：
開放介面層
可直接封裝 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專案中程式碼分層的方案，通過分層之後可以使沒一層更加專注，解除耦合。並簡單介紹了一下分層之後的事務處理和異常處理的邏輯。