Like Share Discussion Bookmark Smile

J.J. Huang   2020-05-17   Java   瀏覽次數:

《阿里Java開發手冊》 | 工程結構 - 應用分層

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

  • 開放接口層:可直接封裝 Service 方法暴露成 RPC 接口;通過 Web 封裝成 http 接口;閘道器控制層等。
  • 終端顯示層:各個端的模板渲染並執行顯示的層。當前主要是 velocity 渲染,JS 渲染,JSP 渲染,移動端展示等。
  • Web 層:主要是對訪問控制進行轉發,各類基本參數校驗,或者不復用的業務簡單處理等。
  • Service 層:相對具體的業務邏輯服務層。
  • Manager 層:通用業務處理層,它有如下特徵:
    • 1.對第三方平台封裝的層,預處理返回結果及轉化異常訊息。
    • 2.對 Service 層通用能力的下沉,如緩存方案、中間件通用處理。
    • 3.與 DAO 層交互,對多個 DAO 的組合復用。
  • DAO 層:資料訪問層,與底層 MySQL、Oracle、Hbase、OB 等進行資料交互。
  • 外部接口或第三方平台:包括其它部門 RPC 開放接口,基礎平台,其它公司的 HTTP 接口。

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


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

  • DO(Data Object):此對象與資料庫表結構一一對應,通過 DAO 層向上傳輸資料源對象。
  • DTO(Data Transfer Object):資料傳輸對象,Service 或 Manager 向外傳輸的對象。
  • BO(Business Object):業務對象,可以由 Service 層輸出的封裝業務邏輯的對象。
  • Query:資料查詢對象,各層接收上層的查詢請求。注意超過 2 個參數的查詢封裝,禁止使用 Map 類 來傳輸。
  • VO(View Object):顯示層對象,通常是 Web 向模板渲染引擎層傳輸的對象。

心得

看完這篇「應用分層」後,基本上這個架構就是目前多數專案在做使用的,當然一定會有些差別,這邊主要是了解每一層應該放什麼樣的邏輯或是設計在裡面,反而我覺得「分層領域模型規約」這些命名方式,是稍微可以知道一下,當然這也不是一定的啦。

結語

文章越看越多,技術越學越多,就會發現自己的不足;技術學到後面都會想要將基礎再重新在打得更加扎實。

以前在開發覺得理所當然的事情,例如:命名規則、命名規範,照著別人怎麼說就怎麼做的想法,並沒有好好去想為什麼要這樣設計和規範。
於是乎同事們推薦《阿里巴巴Java開發手冊》來做閱讀,書中提到種種規範《正確範例》、《錯誤範例》還有解釋定義說明;我相信在閱讀完這一系列後,一定會更加扎實且實在。

如對此書有興趣,建議去購買官方認證的書籍,給予官方支持。

註:如有侵權,通知即刪。


註:以上參考了
Alibaba-Java-Coding-Guidelines Github
Alibaba-Java-Coding-Guidelines English Version