分層思想，是應用系統最常見的一種架構模式，我們會將系統橫向切割，根據業務職責劃分。MVC 三層架構就是非常典型架構模式，劃分的目的是規劃軟件系統的邏輯結構便于開發維護。MVC：英文即 Model-View-Controller，分成模型層、視圖層、控制層。將頁面和業務邏輯分離，提高應用的可擴展性及可維護性。如圖所示。
事實上，MVC 三層架構只是概念層面的指導思想，我們會將層次結構劃分的更加細致。例如，傳統后端的 MVC 模式對于前后端的劃分界限比較模糊。一般情況下，前端開發人員負責編寫項目的靜態頁面，包括 HTML 頁面、CSS 樣式與 JavaScript 交互部分，并提供給服務端開發人員編寫視圖層業務，甚至有的項目直接讓前端開發人員完成視圖層的業務開發任務。這樣的開發模式造成的問題在于，前后端在開發過程中分工不明確，并且存在相互強依賴，前端開發人員需要關心服務端的業務，服務端開發人員也需要依賴前端的進度。并且隨著 Android、 IOS、 PC 以及 U3D 等多個客戶端加入，程序的開發成本與維護成本會指數級上升。為了提高開發效率，細化職責，前后端分離的需求越來越被重視。前后端分離在于服務端提供 API 接口，前端調用 AJAX 實現數據交互。如圖所示。

此外，隨著數據存儲能力的不斷擴展（MySQL、Oracle、Redis、MongoDB、ElasticSearch、PostgreSQL、HBase 等），以及隨著微服務的流行與普及，我們經常通過 RPC（Dubbo、HSF、Thrift 等）依賴很多外部接口或 HTTP 調用第三方平臺。因此，我們需要一套細致劃分的代碼結構。此外，很多時候，我們在開發過程中，也并沒有把它們職責劃分開。例如，在代碼結構中，我們將非常多的邏輯業務放在了 Controller 層，而只把 Service 作為數據透傳的途徑了。事實上，這個是不對的。無獨有偶，我們還會發現有的項目中在 Dao 層調用遠程服務，也有的會在 Service 層或者 Controller 層進行這樣的操作，由于不同研發同學的習慣不同，或者偷工取巧導致開發代碼風格完全不同，代碼層次結構混亂。

總結一下，MVC 三層架構只是概念層面的指導思想，我們會將層次結構劃分的更加細致。現在，我們來深入探討“如何合理的設計代碼分層，論代碼分層的設計之道”。在筆者看來，合理的代碼分層應該是這樣的。如圖所示。

其中，數據持久層 承載了數據存儲和訪問的能力，它既與底層數據進行交換，包括 MySQL、Oracle、Redis、MongoDB、ElasticSearch、PostgreSQL、HBase 等，又通過 Pxoxy 的代理和包裝與遠程服務數據進行聯動。因此，在業務邏輯層調用時，它對底層的數據實現方式是無感知的，無論是哪種數據存儲方式，以及它是遠程數據，還是本地數據，都可以非常容易的調用。換句話說，我們需要將數據的查詢和更改操作限制在數據持久層，并只能被業務邏輯層訪問。

那么，業務邏輯層 的職責是與數據持久層交互，對多個數據源的操作進行聚合，并且提供組合復用的能力。此外，它也是業務通用能力的處理層，其中還包括緩存方案、消息監聽（MQ）、定時任務等等。此外，我們要將盡可能多的業務處理放在業務邏輯層，包括了參數校驗、數據轉換、異常處理等，而不是在 Controller 再去處理。

筆者認為：請求處理層具有三塊能力，一個是通過模板引擎渲染，例如 FreeMarket、Velocity 的頁面渲染，以及通過 Controller 層封裝的 RESTful API 的 HTTP 接口。如果項目中用到了 Dubbo、HSF、Thrift 等 RPC 服務，我們還需要提供對于的服務給上游的業務方使用，它通過 Service 來實現并暴露成 RPC 接口。這里，Service 的命名是相對的，一般通過 Client 提供接口，通過 Service 實現具體的業務邏輯。

我們了解了邏輯結構，那么，筆者認為比較清晰的物理代碼結構應該是這樣的。

那么，我們可以跨層級調用嗎？筆者認為：我們需要禁止跨層級調用，因為每個層級都自己的職責，并且對上層而言是透明的，就像 OSI 七層協議模型和 TCP/IP 四層協議模型一樣，只有將職責限制在自己的邊界內，整體層次結構才清晰明了。那么對于同級調用，筆者認為在業務邏輯層是允許的，但是，要特別注意循環調用的產生。

現在，我們再橫向理解幾個領域模型：VO、BO、DO、DTO。這個概念，是由阿里編碼規約提到的，由于其業務非常復雜，因此為了更好地進行領域建模和模型隔離，提出了這幾個概念。其中，DO（Data Object）與數據庫表結構一一對應，通過 DAO 層向上傳輸數據源對象。 而 DTO（Data Transfer Object）是遠程調用對象，它是 RPC 服務提供的領域模型。注意的是，對于 DTO 一定要保證其序列化，實現 Serializable 接口，并顯示提供 serialVersionUID，否則在反序列化時，如果 serialVersionUID 被修改，那么反序列化會失敗。事實上，DO 和 DTO 唯一的區別在于，一個是本地數據源的領域模型，一個是遠程服務的序列化領域模型。對于 BO（Business Object），它是業務邏輯層封裝業務邏輯的對象，一般情況下，它是聚合了多個數據源的復合對象。那么，VO（View Object） 通常是請求處理層傳輸的對象，它通過 Spring 框架的轉換后，往往是一個 JSON 對象。例如，你需要解決 Long 類型的數據精度丟失的問題（如果直接傳給 Web 端的話，在 Long 長度大于 17 位時會出現精度丟失），你就可以在 Controller 層通過 @ResponseBody 將返回數據自動轉換成 JSON 時，統一封裝成字符串。

總結一下，分層思想，將系統橫向切割，根據業務職責劃分。劃分的目的是規劃軟件系統的邏輯結構便于開發維護。但是，隨著微服務的演變和不同研發的編碼習慣，往往導致了代碼分層不徹底導致引入了“壞味道”。

總結

以上是生活随笔為你收集整理的代码分层的设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。