應用分層

1. 【推薦】圖中默認上層依賴于下層，箭頭關系表示可直接依賴，如：開放接口層可以依賴于

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

• 開放接口層：可直接封裝 Service 接口暴露成 RPC 接口 ； 通過 Web 封裝成 http 接口 ； 網關控制層等。

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

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

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

• Manager 層：通用業(yè)務處理層，它有如下特征：

1 ） 對第三方平臺封裝的層，預處理返回結果及轉化異常信息 ；

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

3 ） 與 DAO 層交互，對 DAO 的業(yè)務通用能力的封裝。

  DAO 層：數據訪問層，與底層 MySQL 、 Oracle 、 Hbase 進行數據交互。

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

2. 【參考】  （ 分層異常處理規(guī)約 ） 在 DAO 層，產生的異常類型有很多，無法用細粒度異常進行catch ，使用 catch(Exception e) 方式，并 throw new DAOException(e) ，不需要打印日志，因為日志在 Manager / Service 層一定需要捕獲并打到日志文件中去，如果同臺服務器再打日志，浪費性能和存儲。在 Service 層出現異常時，必須記錄日志信息到磁盤，盡可能帶上參數信息，相當于保護案發(fā)現場。如果 Manager 層與 Service 同機部署，日志方式與 DAO 層處理一致，如果是單獨部署，則采用與 Service 一致的處理方式。 Web 層絕不應該繼續(xù)往上拋異常，因為已經處于頂層，無繼續(xù)處理異常的方式，如果意識到這個異常將導致頁面無法正常渲染，那么就應該直接跳轉到友好錯誤頁面，盡量加上友好的錯誤提示信息。開放接口層要將異常處理成錯誤碼和錯誤信息方式返回。

3. 【參考】分層領域模型規(guī)約：

•  DO（Data Object） ：與數據庫表結構一一對應，通過 DAO 層向上傳輸數據源對象。

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

• BO（Business Object） ：業(yè)務對象。可以由 Service 層輸出的封裝業(yè)務邏輯的對象。

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

•  VO（View Object） ：顯示層對象，通常是 Web 向模板渲染引擎層傳輸的對象。