JAVA程式設計規範之應用分層

背景分析

在大型軟體系統設計時，業務一般會相對複雜，假如所有業務實作的代碼都糾纏在一起，會出現邏輯不清晰、可讀性差，維護困難，改動一處就牽一發而動全身等問題。為了更好解決這個問題就有了我們現在常說的分層架構設計。

軟體分層設計

分層設計的本質其實就是将複雜問題簡單化，首先基于單一職責原則(SRP-Single responsibility principle)讓每個對象各司其職，各盡所能。然後再基于“高内聚，低耦合”的設計思想實作相關層對象之間的互動。這樣可以更好提高程式的可維護性和可擴充性，例如生活中的樓宇設計，生日蛋糕設計，企業的組織架構設計等。

分層規範

1、【推薦】圖中預設上層依賴于下層，箭頭關系表示可直接依賴，如: 開放接口層可以依賴于 Web 層，也可以直接依賴于 Service 層，依此類推:

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

終端顯示層 : 各個端的模闆渲染并執行顯示的層。目前主要是 velocity 渲染，JS 渲染，JSP 渲染，移動端展示等。

Web 層 : 主要是對通路控制進行轉發，各類基本參數校驗，或者不複用的業務簡單處理等。

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

Manager 層 : 通用業務處理層，它有如下特征:

1）對第三方平台封裝的層，預處理傳回結果及轉化異常資訊；

2）對 Service 層通用能力的下沉，如緩存方案、中間件通用處理；

3）與 DAO 層互動，對多個 DAO 的組合複用。

DAO 層 : 資料通路層，與底層 MySQL、Oracle、Hbase 進行資料互動。

外部接口或第三方平台 : 包括其它部門 RPC 開放接口，基礎平台，其它公司的 HTTP 接口。

2、【參考】 (分層異常處理規約)在 DAO 層，産生的異常類型有很多，無法用細粒度的異常進行 catch，使用 catch(Exception e)方式，并 throw new DAOException(e)，不需要列印

日志，因為日志在 Manager/Service 層一定需要捕獲并打到日志檔案中去，如果同台伺服器再打日志，浪費性能和存儲。在 Service 層出現異常時，必須記錄出錯日志到磁盤，盡可能帶上參數資訊，相當于保護案發現場。如果 Manager 層與 Service 同機部署，日志方式與 DAO 層處理一緻，如果是單獨部署，則采用與 Service 一緻的處理方式。Web 層絕不應該繼續往上抛異常，因為已經處于頂層，無繼續處理異常的方式，如果意識到這個異常将導緻頁面無法正常渲染，那麼就應該直接跳轉到友好錯誤頁面，加上友好的錯誤提示資訊。開放接口層要将異常處理成錯誤碼和錯誤資訊方式傳回。

3、【參考】分層領域模型規約:

1）DO(Data Object) : 與資料庫表結構一一對應，通過 DAO 層向上傳輸資料源對象。

2）DTO(Data Transfer Object) : 資料傳輸對象，Service 和 Manager 向外傳輸的對象。

3）BO(Business Object) : 業務對象。可以由 Service 層輸出的封裝業務邏輯的對象。

4）Query : 資料查詢對象，各層接收上層的查詢請求。注: 超過 2 個參數的查詢封裝，禁止使用 Map 類來傳輸。