Java開發(fā) 應(yīng)用分層

\1. 【推薦】根據(jù)業(yè)務(wù)架構(gòu)實踐，結(jié)合業(yè)界分層規(guī)范與流行技術(shù)框架分析，推薦分層結(jié)構(gòu)如圖所示，默認(rèn)上層依賴于下層，箭頭關(guān)系表示可直接依賴，如：開放 API 層可以依賴于 Web 層 （Controller 層），也可以直接依賴于 Service 層，依此類推：

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

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

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

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

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

1） 對第三方平臺封裝的層，預(yù)處理返回結(jié)果及轉(zhuǎn)化異常信息，適配上層接口。

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

3） 與 DAO 層交互，對多個 DAO 的組合復(fù)用。

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

? 第三方服務(wù)：包括其它部門 RPC 服務(wù)接口，基礎(chǔ)平臺，其它公司的 HTTP 接口，如淘寶開放平臺、支付寶付款服務(wù)、高德地圖服務(wù)等。

? 外部數(shù)據(jù)接口：外部（應(yīng)用）數(shù)據(jù)存儲服務(wù)提供的接口，多見于數(shù)據(jù)遷移場景中。

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

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

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

? DTO（Data Transfer Object）：數(shù)據(jù)傳輸對象，Service 或 Manager 向外傳輸?shù)膶ο蟆?

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

? Query：數(shù)據(jù)查詢對象，各層接收上層的查詢請求。注意超過 2 個參數(shù)的查詢封裝，禁止使用 Map 類來傳輸。

? VO（View Object）：顯示層對象，通常是 Web 向模板渲染引擎層傳輸?shù)膶ο蟆?/p>