简明扼要的说明一下，vo/dto/entity分别是什么，什么时候该用谁。
vo：是用来把数据返回前端的载具 为什么：因为普遍来说，会在vo里写上有关分页的属性（page/size等）；除此之外，vo里放的属性，应该与你的业务逻辑没有半毛钱关系，单纯就是前端要啥你写啥。
entity：就是体现你数据库的表结构，你表有啥字段它就有啥 为什么：因为现在普遍用mybatisPlus，用entity就会十分方便和高效；换句话说，你不用mp或者其他ORM框架，你甚至可以把所谓的"vo","dto","entity"全都一锅烩放在一个类里。 可能你有疑问，那为什么不把entity直接传前端？有没有一种可能前端会要一些该表结构没有的字段。
dto：接收参数/处理数据
为什么：一般是接收前端请求的参数。更多是处理数据：举例前端需要一个数据，结构是[obj_A{"sx1","sx2",[1,2,3],obj_B{"dx1","dx2"}}],这样的结构可能是好几个entity处理后产生的一个list。
那么处理数据的时候，某个表对应的entity里的字段肯定不够用啊，这时候咋办，那就搞出来一个dto里面的属性有list，有map，可能还有其他的实体类，中间的处理过程全都在dto操作。负责把entity零散的数据整装好漂漂亮亮的交给vo，
或者直接就把dto返前端了。
可能你有疑问，那为什么不直接在vo处理，搞dto不是多此一举吗。你说的还真没错，你非要这么来，那也没问题。但在实际操作中，你可能会发现这样的设计存在一些问题。首先，如果把所有数据处理逻辑放在vo中，可能会导致vo的职责过于庞大，
使其难以理解和维护。其次，由于vo的主要职责是封装页面或组件的数据，如果在其中加入过多的业务逻辑，可能会影响其易用性和可读性。vo人都傻了，你怎么不把entity也给我塞进来，干脆不要用mp了。
总结下，entity没有争议，而vo和dto都可以用来接收参数，也都可以用来返回前端。至于他俩的选择，那就是取决于接收或者返回前端传递的是包含页面参数（分页）。主要还是看每个人公司的具体要求了，有的公司dto里放页面参数的。还有就是对安全的要求性，毕竟dto里的属性很多，可能返回前端会暴露过多的信息。个人认为，严格些就是应该vo是返前端，dto来接参数。既然搞了这个规范，那么前端与后端就是想要解耦对吧，如果还是前后端的字段混乱在一起没有分开，那搞这个的意义何在？
标签：dto,前端,vo,可能,参数,entity From： https://www.cnblogs.com/iRyz/p/17986855