應(yīng)用分層

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

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

• 開放接口層：可直接封裝 Service 接口暴露成 RPC 接口 ； 通過 Web 封裝成 http 接口 ； 網(wǎng)關(guān)控制層等。

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

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

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

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

1 ） 對(duì)第三方平臺(tái)封裝的層，預(yù)處理返回結(jié)果及轉(zhuǎn)化異常信息 ；

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

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

  DAO 層：數(shù)據(jù)訪問層，與底層 MySQL 、 Oracle 、 Hbase 進(jìn)行數(shù)據(jù)交互。

 外部接口或第三方平臺(tái)：包括其它部門 RPC 開放接口，基礎(chǔ)平臺(tái)，其它公司的 HTTP 接口。

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

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

•  DO（Data Object） ：與數(shù)據(jù)庫(kù)表結(jié)構(gòu)一一對(duì)應(yīng)，通過 DAO 層向上傳輸數(shù)據(jù)源對(duì)象。

•  DTO（Data Transfer Object） ：數(shù)據(jù)傳輸對(duì)象， Service 和 Manager 向外傳輸?shù)膶?duì)象。

• BO（Business Object） ：業(yè)務(wù)對(duì)象?？梢杂?Service 層輸出的封裝業(yè)務(wù)邏輯的對(duì)象。

• QUERY ：數(shù)據(jù)查詢對(duì)象，各層接收上層的查詢請(qǐng)求。注：超過 2 個(gè)參數(shù)的查詢封裝，禁止使用 Map 類來傳輸。

•  VO（View Object） ：顯示層對(duì)象，通常是 Web 向模板渲染引擎層傳輸?shù)膶?duì)象。