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类如下：
  1. @Entity
  2. @Table(name = "user")
  3. public class User {
  4.     @Id
  5.     @GeneratedValue(strategy = GenerationType.IDENTITY)
  6.     private Long id;
  7.     private String username;
  8.     private String password;
  9.     private String email;
  10.     private LocalDateTime createTime;
  11.     // Getters and Setters
  12. }

  复制代码

---

2. DTO（Data Transfer Object，数据传输对象）

• 作用：在层间（如Controller层和Service层）通报数据，屏蔽敏感字段，或适配差别场景的输入。
  
• 特点：字段可能与Entity差别，比方排除敏感信息（如密码），或组合多个Entity的字段。
  
• 示例：
  用户注册时，前端可能只必要提交username、password、email，不必要id和create_time。
  对应的DTO类如下：
  1. public class UserDTO {
  2.     private String username;
  3.     private String password;
  4.     private String email;
  5.     // Getters and Setters
  6. }

  复制代码
  使用场景：
  
  
  
  • Controller吸收到UserDTO后，将其转换为User实体，再交给Service层生存到数据库。
    
  • 避免了直接暴露Entity布局，提升安全性（比方密码加密后再存储）。
    
  
  

---

3. VO（View Object，视图对象）

• 作用：返回给前端的展示数据，定制化字段，适配前端需求。
  
• 特点：字段可能与Entity差别较大，比方排除敏感信息、格式化时间、组合多个数据源的结果。
  
• 示例：
  查询用户信息时，前端必要id、username、email和格式化后的createTime，但不必要password。
  对应的VO类如下：
  1. public class UserVO {
  2.     private Long id;
  3.     private String username;
  4.     private String email;
  5.     private String formattedCreateTime; // 例如：2024-01-01 12:00:00
  6.     // Getters and Setters
  7. }

  复制代码
  使用场景：
  
  
  
  • 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企服之家，中国第一个企服评测及商务社交产业平台。