我特麼？暴怒！！DO BO VO DTO 究竟是個啥 ？

序

各位，既然點進來了，那麼你們都必定是對 DO、BO 、VO、DTO 心中抱有疑問。 這些到底是個什麼？怎麼用？爲何這樣分？ 在這裏都將給你答案。

是什麼？

首先，他們都是 POJO 也就是咱們 JAVA 自定義的類，不一樣的是層級和屬性的差異

DO（Data Object）數據層對象 該對象屬性與 數據庫表字段一一對應 如 DyinggqDO

BO（Business Object）業務層對象 該對象對應 Service 層，即經常使用開發中 XxxServerImpl 中使用的對象，它與 DO 會有必定的屬性差異，一般咱們會給出 DO 到 BO 的轉換方法，或者使用 Mapper 工具包。如 DyinggqBO

VO（View Object）顯示層對象 該對象一般對應於 Controller 層，即咱們要最終返回給前端的 JSON 序列化對象。如 DyinggqVO

DTO（Data Transfer Object）數據傳輸對象 數據傳輸對象，這個名詞初看有點蒙。這樣理解，RPC 接口請求接收的對象，或者提供 RPC 接口傳輸出去的對象，又或者在咱們 JAVA 內部調用外部 API JSON 解析 的對象，咱們均可以定義爲 DTO。如 DyinggqDTO

爲何？

1.爲何要區分這些？

如咱們在項目包結構分層同樣，區分 POJO 有助於代碼的整潔，各司其職，不易混淆亂用，並且在大型項目及複雜場景確實須要如此區分，即需求所在。

2.爲何要區分 DO 和 BO ？

在比較複雜的業務場景下，咱們的 Service 層所要使用的 POJO 是 DO 即單表對應類沒法知足的，不少狀況下在 Service 層可能 BO 會聯合幾個表進行聚合定義，其屬性是聚合處理出來的，可能會有列表或者計算得出的字段，全部 BO 與 DO 的區分是頗有必要的。固然在簡單的場景下咱們直接使用 DO 也並無任何問題，只在真正須要的時候才進行區分定義纔是正確的代碼之道。

3.爲何還要有 VO ？

很簡單的思考，前端並不須要後臺全部的數據，對應在接口中，咱們只須要返回給他們須要的字段就能夠了，避免垃圾數據的傳遞以及沒必要要的數據泄露，咱們儘量少的供給前端，讓前端本身在他的一畝三分地玩好就行。

3.爲何還要有 DTO ？

通過上面的解釋，這個爲何應該很天然而然了吧，很顯然 外部請求回來的對象 咱們區分一下 定義爲 DTO 。舒服的一批好嘛

最後

最後真正須要才區分使用，懂怎麼用，知什麼時候用，但願本文對你有所幫助

我是 dying 擱淺 ，我始終期待與你的相遇。不管你是否期待，潮漲潮落，我僅且就在這裏…