目录
1. 前言
2. POJO的含义
3. entity(实体)
4. model(模型)
5. domain(域)
6. view(视图)
7. DTO(数据传输对象)
8. VO(真正视图层)
9. Param(参数)
10. 总结
1. 前言
在日常开发的过程中，如果我们接手一个新的项目之后，通常会有各种各样的包，想要搞清楚项目的基本架构，当然就需要知道各种包做什么用的，里面存放了那些东西。以便于我们理解项目的整体结构。
我们都知道项目是要和数据库打交道的，数据库中的一张表映射到Java代码种是一个实体类。在形目中，我们通常会发现实体类用很多种不同的定义方法，有叫 entity 的，有叫 domain 的，有叫 model 的，有叫 pojo 的，到底哪一种是最规范的呢？本篇我们就来说说它们的区别。
2. POJO的含义
POJO 英文全称"Plain Ordinary Java Object"，译为普通的Java对象，就是我们常说的 JavaBean 对象。在 JavaBean 对象中，通常会定义 Getter 和 Setter 方法以便于我们在业务层对对象属性值的存取操作。
而 entity，domain，model，view，DTO，VO都可以理解为 JavaBean，也都可以理解为POJO，POJO是它们的抽象，但是细分它们的区别，还是会有所不同的。
3. entity(实体)
entity 实体类中的属性通常与数据库中的一张表的字段完全相应。
如下是一张用户表 user，表中有以下六个字段值；
那么 user 表对应的 entity 实体类 User 如下所示，通常类中的字段会与数据库表中的字段一一对应；
@Data
public class User {
private Long uid;
private String username;
private String password;
private int age;
private String email;
private String sex;
}除此之外，还会有一些特殊情况，比如所有的 entity 类可能都会继承某个基类 BaseEntity；
就拿上面的 user 表来说，如果 user 数据库表中定义了BaseEntity类中的四个字段，通常都是需要去继承BaseEntity类的；
如果 user 数据库表中没有定义BaseEntity类中的四个字段，那么user类可以选择继承BaseEntity类，也可以选择不继承BaseEntity类。
换句话来说就是，JavaBean类中定义的属性可以比数据库表中的字段多，也可以和数据库表中的字段相等，也可以比数据库中的字段少；但一般情况下都是一一对等的关系。
@Data
public class BaseEntity {
private String createUsername;
private Date createTime;
private String updateUsername;
private Date updateTime;
}4. model(模型)
model 实体类中的属性通常可能含有数据库中多张表的字段；
有些业务中，我们可能会去操作多张表。
举个例子，假如说某个业务需要查询AB两张表，A表中有一个a1，a2，a3字段，B表中有一个b1，b2，b3字段。
SELECT *
FROM A INNER JOIN
ON A.a1 = B.b1
WHERE A.a2 = #{model.a2} AND B.b2 = #{model.b2}这个时候，加入我们想要用一个实体类传参达到效果，就必然要求这个实体类中既含有A类中字段属性，有含有B表中的字段属性；这种实体类我们就可以称之为 model 实体类
@Data
public class SelectModel {
private String a2;
private String b2;
}5. domain(域)
domain 中通常可能含有多张表映射的Java对象；
还有一种业务需求，可能需要查询多张表，然后将查询到的数据全部返回；
此时我们就可以创建另外一种实体类，该实体类中的属性不是八种基本数据类型，而是其他自定义实体类，我们将查询到但表数据封装到对应的实体类中，再将多张表查询到的数据汇总到一起封装到 Domain 类中，这就是域
@Data
public class SelectDomain {
private xxxEntity1 entity1;
private xxxEntity2 entity2;
private xxxEntity2 entity3;
}6. view(视图)
view 中通常含有数据库中多张表的部分字段；
视图我们就可以理解为呈现的东西，在程序中，视图就是展示给用户的数据。
举个栗子：如下为用户表对应的实体类 User；
@Data
public class User {
private Long uid;
private String username;
private String password;
private int age;
private String email;
private String sex;
}在实际的业务中，假设用户登陆成功，我们不一定需要将用户的密码也展示出来，也不一定需要将用户的ID展示出来，假设用户登陆后只显示用户名和邮箱，我们就重新定义一个视图实体类 UserView，里面只定义username和email两个属性；
由此就有了视图 view，在 view 中，我们只会定义需要展示给用户看的字段属性；
这样我们在进行数据库查询的时候，也是只查询这两个字段的值，返回值类型就是用 UserView 来接收，而不使用 User 实体类来接收；
@Data
public class UserView {
private String username;
private String email;
}7. DTO(数据传输对象)
这个其实和刚才我们说的 view 是有非常类似的，只是叫法不同，就不做过多的叙述了；
8. VO(真正视图层)
VO 就是我真正展示给用户去看的数据字段；
VO全称 View Object，视图对象，很多小伙伴可能会有疑惑，DTO和view不是已经起到了视图层数据传输的效果了吗？为什么还要使用VO呢？
其实不然，小伙伴们可能知道，在一些庞大复杂的项目中，数据库表和表之间的外键约束会非常密切，这样一来，我们数据库表中存储的数据大多都是其他表的主键ID，并不会存储具体的信息。
这样一来，我们数据库查询之后得到了一堆其它表的主键ID，但这并不是我们想要的结果，所以我们需要在业务层再去根据这些主键ID去各自对应的数据库表中查询用户想要的数据，然后在返回，查询到的数据我们通常会使用VO类来进行接收，查询完毕，我们将VO返回给前端展示，这才算是一个业务流程真正完成。
9. Param(参数)
通常封装对数据库中字段做修改的数据或查询条件属性；
业务层中的方法，大多都会采用实体类型传参，因此通常会定义一个xxxParam实体类，实体类中封装一些要对数据库表中字段进行修改的操作或是查询条件字段；
10. 总结
虽然上面它们细分下来会有一些不同，但在实际的项目中，开发人员不一定会严格按照它们的规范去进行开发，但一个项目中一般都会包含以下集中实体类型。
第一种：entity 实体数据访问层，专门用来对数据库单表进行数据操作；
第二种：view，DTO数据传输层，通常用作接收单表或夺表查询到的部分字段；
第三种：VO视图层，通常用于存储页面真正展示的数据；
第四种：Param 参数实体，通常用于封装前端传递过来的数据，后端可以根据Param中的参数对单表或多表进行CRUD操作；
参考：史上最全总结！Util、POJO、domain、entity、model、DAO、DTO、view、mapper、service、controller的作用和区别分析_model entity view-CSDN博客
