pojo与DTO的区别是什么

DTO (Data Transfer Object)数据传输对象：主要用于远程调用等需要大量传输对象的地方。

BO(business object) 业务对象：从业务模型的角度看,见UML元件领域模型中的领域对象封装业务逻辑的java对象,通过调用DAO方法,结合PO,VO进行业务 *** 作

POJO(plain ordinary java object) 简单无规则java对象

纯 的传统意义的java对象就是说在一些Object/Relation Mapping工具中,能够做到维护数据库表记录的persisent object完全是一个符合Java Bean规范的纯Java对象,没有增加别的属性和方法我的理解就是最基本的Java Bean,只有属性字段及setter和getter方法!

PO(persistant object) 持久对象

在o/r 映射的时候出现的概念,如果没有o/r映射,就没有这个概念存在了通常对应数据模型(数据库),本身还有部分业务逻辑的处理可以看成是与数据库中的表相映射的java对象最简单的PO就是对应数据库中某个表中的一条记录,多个记录可以用PO的集合PO中应该不包含任何对数据库的 *** 作

在我使用mybatis plus开发的项目中，总结出几条经验：

1、单表最简单

直接Wrapperquery构建QueryWrapper查询对象，也可以通过集成Model，得到一系列的加强功能，可以说单表 *** 作，其灵活性和简便、性能，和JPA一样牛B（我用过一段时间的JPA，使用repository查询也很方便）。

在Controller层，VO常常被我用来简化返回的对象，毕竟BeanUtil还是挺好用的，追求性能的话，恰好IDEA有个插件可以很好的实现手动版赋值拷贝。

DTO再单表 *** 作的时候，作用就不是那么的明显了，为了偷懒，一个VO跑所有，我知道不好，没办法就是懒。

简单总结：单表 *** 作，vo，dto主要用来简化对象的属性，不能一个请求连User的password都丢出去吧，明文密码的现象有木有。

2、联表查询

使用Mybatis plus联表查询，基本上就退回到mybatis的层面了，VO/DTO这个时候就算是比较好的补充了，反正有的人喜欢SQL,有的喜欢对象 *** 作，还有注解型、xml型，玩法真多。

A、一对多的场景：

Controller(使用VO接收和返回，基本上可以做到一个请求完成所有需要的data)，当请求到达Controller后转发给Service，使用我们可以开始拆分成不同的dto来使用了。Service入参的时候，有两个选择：从VO提取需要的参数封装成Map对象，调用Wrappersquery查询；或者封装成入参DTO，方便复用，这里根据场景选择；返回时DTO就有必要了，一边来说，到了Service层我们不会考虑数据脱敏等安全问题，我们考虑性能。您可能会说，不该mybatis的默认service返回的都是数据实体对象，装DTO岂不是浪费，NONono,喜欢SQL的同学对dto一定是喜欢的不得了，返回DTO不至于出现数据实体的残躯（属性缺胳膊少腿）。喜欢默认Service的同学，看好了，我说的是一对多的场景，我给点提示"多线程"，将无数个小DTO通过并行的方式，拷贝给VO实行组装，速度提升不是的一两点，特别是一个好大的页面请求，还有别忘记“同步锁”。那种CPU狂飙的感觉，爽。

B、多对多（不常见）

见过意大利面吗，一团一团，前台的同学，一个form请求过来，可能连参数名都对不齐。一般情况下，我建议大家直接拒绝请求。但如果对方付了RMB的话，（比如你是一个接口商），我们还是要勉强抬抬眼皮的。多对一的场景出现在一个不常见的场景，比如说：我们的接口需要一次接收多个对象组装的data，第一选择，拆成小dto，传给各自的mapper，返回的时候组装自己的VO。第二选择，BeanUtils又来了，属性拷贝走起Wrppers查询，再用VO封装；第三选择，性能最好的，写SQL。他们丢再大的参数我也不怕了。

总结：

VO：简单的时候可以替代dto从前跑到后；

DTO：只在Service,mapper层跑；

要会拆，能拆。充分利用mybatis plus的条件查询，因为太爽了。对象查询可能会慢，但我们的时间更重要，不是吗？

最后，这是一篇水文。

以上就是关于pojo与DTO的区别是什么全部的内容，包括:pojo与DTO的区别是什么、java项目中VO和DTO以及Entity，各自是在什么情况下应用的、顶呱呱啊！更便捷的Mybatis增强插件——EasyMybatis等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！