DTO 和 VO 的核心区别
| 特性 | DTO（数据传输对象） | VO（视图对象） |
|---|---|---|
| 设计目的 | 服务层与外部系统（如前端、其他服务）之间的数据传输 | 为前端展示层定制数据，通常与 UI 强绑定 |
| 数据内容 | 可能包含业务逻辑需要的字段（如 ID、状态码等） | 仅包含前端需要的字段，可能包含格式化后的数据 |
| 格式控制 | 保持原始数据格式，不处理 UI 展示细节 | 可能包含格式化后的日期、金额、多语言文本等 |
| 复用性 | 可能被多个接口复用（如不同端的前端、App） | 通常针对特定页面或组件定制，复用性较低 |
| 层级归属 | 通常属于服务层或接口层的模型 | 属于表现层（Controller 或前端直接使用的模型） |
实际场景举例
场景：订单详情接口
DTO（Response 方向）
java
复制
下载
public class OrderDTO { private Long orderId; private BigDecimal amount; private LocalDateTime createTime; // 原始时间戳 private String status; // 业务状态码（如 "PAID"） }用于服务层返回给 Controller 的原始数据。
可能被多个消费者复用（如 App、H5、第三方系统）。
VO（前端展示）
java
复制
下载
public class OrderVO { private String orderNo; // 格式化的订单号（如 "ORDER-20231001-001"） private String displayAmount; // 格式化后的金额（如 "￥199.00"） private String createTime; // 格式化后的时间（如 "2023-10-01 14:30"） private String statusLabel; // 状态文案（如 "已支付"） }由 Controller 或工具类将
OrderDTO转换而来。直接面向页面展示需求，包含 UI 需要的额外字段（如状态文案、格式化数据）。
为什么需要区分？
解耦业务逻辑与 UI 逻辑
DTO 保持业务数据的纯粹性，VO 处理 UI 展示细节（如日期格式化、多语言）。
修改 UI 展示逻辑时，无需影响服务层的 DTO。
避免接口污染
如果直接返回 DTO 给前端，可能暴露敏感字段（如数据库 ID、内部状态码）。
VO 可以隐藏不必要的字段，保障数据安全性。
适应多端差异
同一 DTO 可能被不同端（Web、App、第三方）复用，但每个端的 VO 展示需求不同。
代码可维护性
当 UI 展示逻辑变化时（如状态码映射调整），只需修改 VO 转换逻辑，无需改动服务层代码。
目录结构建议
如果项目中 DTO 和 VO 的职责明确，可以进一步细分目录：
bash
复制
下载
src/main/java/com/example/project/
└── model/
├── dto/
│ ├── request/ # 入参 DTO（如 OrderCreateRequest）
│ └── response/ # 出参 DTO（如 OrderResponse）
└── vo/ # 视图对象（如 OrderDetailVO）
什么情况下可以合并？
在小型项目或简单接口中，如果以下条件满足，可以合并 DTO 和 VO：
前端展示字段与 DTO 完全一致。
无需隐藏敏感字段。
没有多端复用需求。
但需注意：随着项目复杂度上升，合并后的模型可能难以扩展。
总结
DTO 是面向接口的通用传输模型，关注数据完整性和跨系统兼容性。
VO 是面向 UI 的定制模型，关注展示友好性和安全性。
两者分离是分层架构的体现，能显著提升代码的灵活性和可维护性。