与好友“浩南“除夕讨论DTO，entity(POJO)，VO有感

首先声明下面是个人所想，并不一定正确，大家有不同的想法，欢迎在下方评论区进行讨论，多交流才能有不一样的理解！

1.先说明DTO与VO定义，entity就不说了，大家都懂。

DTO:数据传输对象（DTO)(Data Transfer Object)，是一种设计模式之间传输数据的软件应用系统。数据传输目标往往是数据访问对象从数据库中检索数据。数据传输对象与数据交互对象或数据访问对象之间的差异是一个以不具有任何行为除了存储和检索的数据（访问和存取器）。

VO：这里的VO是指(View Object)视图对象，通俗的来说指的是包含前端页面需要展示的信息的一个对象。

2. entity(POJO),DTO与VO有什么关系？

首先POJO就是对应与数据库中各种表，并且里面的字段是一一对应的，这我想是共识。

DTO的话，在我看来它是在POJO的基础上删减（我们不想透露的信息）或者增加（我们需要显示的信息）了某个字段而形成的一个实体类。

VO的话，在我看来它是包含前端页面想要展示信息的一个对象，VO可以由不同的DTO组成。

3.举个栗子

如上图，这是一篇微博的截图，我们可以把其简单的分为三部分组成，蓝色框的用户数据（用户头像和用户姓名），红色框的帖子信息以及黑色框的相关评论信息，由这个页面需要展示的信息来说，我们可以定义一个VO对象，包含其中的需要展示的信息，那么这个VO该由什么组成是我们所关注的一点，VO中所有展示的消息都可以从我们的POJO（数据库表）中获取到，而如何将POJO中的信息转换称为VO对象是我们关注的要点。而上面所说的DTO就是这样一个起着桥梁作用的对象。

通过观察我们可以看的出，帖子和对应的评论信息中有着共同的部分，即用户的头像和用户名，这都是属于用户数据，所以我们可以设计一个UserDto来保存所需要的信息，但是这个UserDto又与我们的User类有一些区别，在UserDto中只含有在前端上我们想要的数据，并不仅仅局限于这里的用户名和头像。同理，帖子信息可以用一个PostDto来保存，评论信息可以用CommentDto保存。

从而这整个页面对应的VO对象就是由这三个DTO组合而成。我们可以根据我们的POJO类，扩展出相应需要的DTO类，而前端页面所需要展示的信息则有VO来代表，从而每个VO都是由不同的DTO所组成，当然VO也可以包含其它VO，就像搭乐高积木一样，DTO就是一个个积木块。这样设计的一个好处是，数据查询的SQL语句可以简单很多（至少我是这么认为，如果有不对，请纠正）。

这样设计以后，如果页面需要展示的信息更改了，我们也只需要更改组成该VO对应的DTO。

4.结束

以上只是一个菜鸟的一番见解，是我从前端页面的角度出发，有关一番VO与DTO的解释，所以难免有不正确的地方，如有不当，请指出！

“浩南”和我说，如果每个VO都是DTO的组合的话，会存在很高的耦合性，但是我并不认同这句话，就比如内存插条一样，只要符合插槽的接口，管你是多少G内存（打个比方，可能不太恰当）。