关于DTO的理解

原创已于 2025-05-30 08:12:51 修改 · 715 阅读

CC 4.0 BY-SA版权

文章标签：

于 2025-05-30 08:06:04 首次发布

8 篇文章

订阅专栏

2 篇文章

订阅专栏

理解 DTO（Data Transfer Object，数据传输对象） 的核心在于它的名字：它是专门为了在网络或进程间传输数据而设计的对象。

纯数据容器： DTO 的主要目的是承载数据。它通常只包含字段（属性）和访问这些字段的方法（getter/setter），不包含任何业务逻辑。
传输优化： 它的设计是为了高效、安全地传输数据，尤其是在跨网络（如客户端-服务器、微服务之间）或跨应用层（如表现层到服务层）的场景。
解耦： DTO 充当了不同系统、服务或应用层之间的契约（Contract）。它定义了双方通信时数据的格式和结构，解耦了内部数据模型与外部接口。

想象一下没有 DTO 的情况：

暴露内部细节： 直接将你的领域模型（Domain Model） 或实体（Entity） 对象（例如数据库映射的 User 对象）通过网络发送给客户端或另一个服务。这会导致：
- 安全风险： 暴露了敏感字段（如 password, salt, internalId）。
- 过度传输： 发送了大量客户端不需要的字段，浪费带宽和解析时间。
- 耦合： 客户端或服务端必须了解对方内部模型的细节，一方模型改变可能破坏另一方。
传输效率低下： 需要传输的数据可能来自多个不同的内部对象或数据源，直接传输这些原始对象可能结构复杂或冗余。
接口定制化困难： 不同接口（API Endpoint）可能需要返回相同核心数据的不同视图（例如，用户列表接口只需要 id 和 name，而用户详情接口需要更多信息）。直接用同一个模型对象无法灵活满足。

定制化视图： 为特定的接口或交互场景创建专门的 DTO。只包含该场景下必需且安全的字段。
- 例如：UserSummaryDTO (只包含 id, username, avatarUrl) 用于列表展示；UserDetailDTO (包含 id, username, email, registrationDate) 用于详情页；发送给客户端的 DTO 绝不包含 password 或 salt。
聚合数据： 一个 DTO 可以组合来自多个领域对象或数据源的数据。
- 例如：OrderDetailsDTO 可能包含来自 Order 实体的基本信息、来自 User 实体的买家信息、来自 Product 实体的商品信息列表等。
扁平化结构： 将复杂的嵌套对象结构简化、扁平化，使其更适合网络传输和客户端解析。
版本控制： 作为接口契约，DTO 的版本更容易管理。可以创建 UserDTOV1, UserDTOV2 来支持不同版本的 API 客户端，而内部领域模型可以独立演进。
减少传输量： 只传输必要的字段，显著减少网络负载。

客户端请求： 客户端（浏览器、App）发起一个 API 请求（如 GET /api/users/123）。
服务端处理：
- 控制器（Controller）接收请求。
- 服务层（Service）被调用，执行业务逻辑。
- 服务层可能访问数据库，获取一个或多个领域模型/实体对象（如 User 实体）。
DTO 组装： 服务层或专门的映射层（如 MapStruct, ModelMapper, 或手动代码）将获取到的领域模型/实体对象转换成针对该 API 设计好的 DTO 对象（如 UserDetailDTO）。这个过程会：
- 选择需要的字段。
- 排除敏感或不必要的字段。
- 可能组合、计算或格式化数据。
返回响应： 控制器将组装好的 DTO 对象 序列化（如转换成 JSON/XML）并通过网络发送回客户端。
客户端使用： 客户端接收并反序列化 JSON/XML 为它理解的 UserDetailDTO 对象（或等效结构），用于展示或进一步处理。

Entity / Domain Model： 代表业务领域核心概念，包含数据和业务逻辑，与持久化（数据库）紧密相关。DTO 是它的一个“视图”或“投影”，用于传输。
VO (Value Object)： 代表一个不可变的、描述某个属性的值（如 Money 包含金额和货币）。VO 是领域模型的一部分，可能包含逻辑。DTO 纯粹用于传输。
POJO / PO (Plain Old Java/Object)： 指简单的、不依赖特定框架的 Java/Object 类。DTO、Entity、VO 都可以是 POJO/PO。POJO/PO 是一个更宽泛的概念。
DAO (Data Access Object)： 用于封装对数据源（数据库）的访问操作。与 DTO 目的完全不同。