我特么？暴怒！！DO BO VO DTO 到底是个啥？

落日映苍穹つ 2023-01-15 14:21 82阅读 0赞

### 序 ###

各位，既然点进来了，那么大家都一定是对 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 搁浅][dying] ，我始终期待与你的相遇。无论你是否期待，潮涨潮落，我仅且就在这里…**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3c5MDMzMjg2MTU_size_16_color_FFFFFF_t_70]

[dying]: https://blog.csdn.net/w903328615
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3c5MDMzMjg2MTU_size_16_color_FFFFFF_t_70]: /images/20221022/664c5e52eaa34149a541ad2a54347580.png