目錄

• 概念
• • 關于do的理解
• 業務邏輯分層
• 基于springboot的邏輯分層結構
• 什么時候需要定義這么多O
• 實際項目中的使用方式
• • 同一微服務中
  • 不同微服務
  • 一般起名規則

---

概念

• VO（View Object）：視圖對象，用于展示層，它的作用是把某個指定頁面（或組件）的所有數據封裝起來。
• DTO（Data Transfer Object）：數據傳輸對象，這個概念來源于J2EE的設計模式，原來的目的是為了EJB的分布式應用提供粗粒度的數據實體，以減少分布式調用的次數，從而提高分布式調用的性能和降低網絡負載，但在這里，更符合泛指用于展示層與服務層之間的數據傳輸對象。
• BO（Business Object）：業務對象，把業務邏輯封裝為一個對象，這個對象可以包括一個或多個其它的對象。
• PO（Persistent Object）：持久化對象，它跟持久層（通常是關系型數據庫）的數據結構形成一一對應的映射關系，如果持久層是關系型數據庫，那么，數據表中的每個字段（或若干個）就對應PO的一個（或若干個）屬性。
• DO（Domain Object）：領域對象，就是從現實世界中抽象出來的有形或無形的業務實體。

關于do的理解

do和po很難理解，這個地方舉個例子，比如我有一個po存儲了某種商品的價格原始信息，但是當我的service中要讀取商品的價格信息的時候，除了需要這些原始信息，還需要根據折扣再要基準折扣價之類的信息，而這類信息是要通過數據庫中已有信息計算得到的。
簡而言之，service在讀取po的時候，需要在po外增補一些冗余數據、而這些數據，通常不會保存在數據庫中，但又是多個service共用的。這類數據

放在service中new一個自定義對象不合適，因為其他service中也經常要用，這樣無法做到service間代碼的復用

直接用po也不合適，因為po是直接操作數據庫對象的，數據庫中也沒有這個冗余字段。

所以此時最好是在serveice層和dao層之間，再抽象出一個o，其中不只存放了po的基礎信息，還存儲了一些基于po的冗余計算屬性，或者對po做一些魔改。
但是現在由于使用的jpa或mybatis框架，是支持標明entity中哪些屬性是db的原始屬性，哪些屬性不是db中的屬性的，實際上做的事情就是將do和po做了整合，以后可以認為不需要單獨再搞一個do對象進行數據操作了。

業務邏輯分層

M層負責與數據庫打交道；

C層負責業務邏輯的編寫；

V層負責給用戶展示（針對于前后端不分離的項目，不分離項目那種編寫模版的方式，理解V的概念更直觀）。

基于springboot的邏輯分層結構

以上邏輯分層翻譯成常見的springboot結構就是

什么時候需要定義這么多O

項目中真的有必要定義VO，BO，PO，DO，DTO嗎？按照理論上來講

• 如果項目比較小，是一個簡單的MVC項目，又是單兵作戰，我不建議使用VO，BO，PO，DO，DTO，直接用POJO負責各個層來傳輸就好，因為這種項目的“目的地”是快速完成。
• 而我們更多的時候，是持續迭代的團隊協作項目，這個時候我們就建議用VO，BO，PO，DO，DTO，而且團隊內要達成共識，形成一個標準規范。

目的是提升項目的可擴展性、可維護性與可閱讀性。

其實要不要用這么多o，關鍵問題在于關注controller、service、dao這些層間數據有沒有變化。比如vo傳進來，放進service直接拆成po，那就沒有dto什么事。如果存在rpc調用，就需要考慮一下，要不要新加一個object。對象數量的選擇，完全根據層間數據變化來決定

實際項目中的使用方式

同一微服務中

一般controller向service傳的數據和service向controller傳的數據不一定相同，這就導致每層的dto、po等對象都可能有兩個

不同微服務

因為不同微服務中涉及到RPC遠程調用，所以經常會有重復的object對象出現在不通服務中。

一般起名規則

名稱中，要寫明對象涉及的兩層邏輯，最好再寫明數據流向。

總結

以上是生活随笔為你收集整理的vo、dto、bo、do、po的概念理解以及与controller、service、dao层的对应关系的全部內容，希望文章能夠幫你解決所遇到的問題。

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