應用分層


1. 【推薦】圖中預設上層依賴下層，箭頭關係表示可直接依賴，如：開放介面層可以依賴

Web 層，也可以直接依賴Service 層，依此類別推：

QQ截图20170211103016.png

  • 開放介面層：可直接封裝Service 介面暴露成RPC 介面； 透過Web 封裝成http 介面；閘道控制制層等。

  • 終端機顯示圖層：各端的範本渲染並執行顯示圖層。目前主要是 velocity 渲染， JS 渲染， JSP cap染，行動端展示層等。

  • 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. 【參考】分層領域模型規則：

  •  DO（Data Object） ：與資料庫表結構一一對應，透過 DAO 層向上傳輸資料來源物件。

  •  DTO（Data Transfer Object） ：資料傳輸對象， Service 和 Manager 向外傳輸的對象。

  • BO（Business Object） ：業務物件。可以由 Service 層輸出的封裝業務邏輯的物件。

  • QUERY ：資料查詢對象，各層接收上層的查詢請求。注意：超過 2 個參數的查詢封裝，禁止使用 Map 類別來傳輸。

  •  VO（View Object） ：顯示圖層對象，通常是 Web 傳送到範本渲染引擎層的對象。