Spring学习条记05——Spring Boot的文件布局2（POJO类）
在Spring Boot项目中，将Entity、DTO、VO放在POJO子模块中是一种常见的分层设计，它们各自尊担差别的职责，通过一个通俗的例子来表明它们的作用：POJO（Plain Old Java Object）是指普通的、简单的Java对象，只有属性和对应的setter和getter方法，不依赖于任何特定的框架、接口或父类。它的核心头脑是保持代码的简洁性和可移植性，避免与特定技术绑定。
Entity、DTO、VO 都属于 POJO，它们是具有特定用途的POJO。下面具体讲解。
1. Entity（实体）
[*]作用：直接对应数据库表，用于ORM框架（如Hibernate）操作数据库。
[*]特点：字段与数据库表严格一致，可能包罗关联关系（如外键）。
[*]示例：
假设有一个用户表user，包罗字段：id、username、password、email、create_time。
对应的Entity类如下：@Entity
@Table(name = "user")
public class User {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String username;
private String password;
private String email;
private LocalDateTime createTime;
// Getters and Setters
}
2. DTO（Data Transfer Object，数据传输对象）
[*]作用：在层间（如Controller层和Service层）通报数据，屏蔽敏感字段，或适配差别场景的输入。
[*]特点：字段可能与Entity差别，比方排除敏感信息（如密码），或组合多个Entity的字段。
[*]示例：
用户注册时，前端可能只必要提交username、password、email，不必要id和create_time。
对应的DTO类如下：public class UserDTO {
private String username;
private String password;
private String email;
// Getters and Setters
}
使用场景：
[*]Controller吸收到UserDTO后，将其转换为User实体，再交给Service层生存到数据库。
[*]避免了直接暴露Entity布局，提升安全性（比方密码加密后再存储）。
3. VO（View Object，视图对象）
[*]作用：返回给前端的展示数据，定制化字段，适配前端需求。
[*]特点：字段可能与Entity差别较大，比方排除敏感信息、格式化时间、组合多个数据源的结果。
[*]示例：
查询用户信息时，前端必要id、username、email和格式化后的createTime，但不必要password。
对应的VO类如下：public class UserVO {
private Long id;
private String username;
private String email;
private String formattedCreateTime; // 例如：2024-01-01 12:00:00
// Getters and Setters
}
使用场景：
[*]Service层查询到User实体后，将其转换为UserVO，再通过Controller返回给前端。
[*]避免暴露数据库细节，提升接口灵活性。
总结：三者的协作流程
[*]用户注册：
[*]前端提交UserDTO → Controller吸收 → Service层将UserDTO转为User实体 → 存入数据库。
[*]查询用户信息：
[*]Service层查询User实体 → 转为UserVO → Controller返回UserVO给前端。
备注：主流规范的做法应该是Controller吸收到DTO后，在Controller层将DTO转为Entity，再交给Service处理。在一些极简单项目（不严格分层时），也可能会由Service层进行转换。
关键区别
类型用途字段特点生命周期Entity直接操作数据库与数据库表严格一致持久化层（数据库操作）DTO层间数据传输（如Controller ↔ Service）可能比Entity少字段，或增加校验逻辑哀求处理阶段VO返回给前端的展示数据定制化字段，适配前端需求响应天生阶段 为什么分层？
[*]安全性：避免将Entity直接暴露给前端（如隐藏密码）。
[*]灵活性：Entity、DTO、VO可独立变化，互不影响（比方数据库字段变更只需调整Entity）。
[*]解耦：各层职责清晰，Controller不依赖数据库布局，Service不依赖前端需求。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]