我特么？暴怒！！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 搁浅 ，我始终期待与你的相遇。不管你是否期待，潮涨潮落，我仅且就在这里…