Java中domain和dto区别小结

2026-07-27 08:30:44 作者：前端工作日常

本文主要介绍了Java中domain和dto区别小结,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧

核心概念

Domain（领域模型）/实体（Entity）：通常映射到数据库表（JPA 中的 @Entity，MyBatis 中的 POJO）。包含数据 + 业务逻辑（通常只是数据，带有贫血模型，但在更广泛的意义上，它代表业务实体）。
DTO（数据传输对象）：为传输而设计的普通数据容器（API 请求/响应、RPC 调用）。无业务逻辑。专为特定用例（如 UI 视图）量身定制。

1. Domain 和 DTO 的异同

对比维度	Domain（领域对象 / PO / Entity）	DTO（数据传输对象）
核心职责	持久化：负责与数据库表结构一一映射（ORM）。	传输：负责在“后端”与“前端（或第三方接口）”之间传递数据。
包含属性	全量字段：包含数据库表中所有的列（比如：id, name, password, salt, create_time, update_time）。	部分字段：只包含前端当前页面需要的字段（比如：只返回 id 和 name，不要 password）。
包含逻辑	可以有业务逻辑：可以包含一些针对该实体类的校验方法或业务计算方法。	纯数据载体：只应该有字段和 getter/setter，绝对不包含任何业务逻辑。
敏感信息	包含敏感信息：直接包含数据库里的密码、加密盐值等。	过滤敏感信息：严禁包含密码、身份证号等不该暴露给前端的数据。

如果偷懒不分层，直接把 Domain 对象返回给前端（Controller 层直接返回 Entity），你会遇到以下 3 个致命问题：

① 安全问题（最严重）：你的 Domain 对象里一定有 password（密码密文）和 salt（盐值）。如果你直接把 Domain 传给前端，这些敏感数据就会被接口泄露出去。而 DTO 可以只挑出 username 和 avatar 返回。
② 接口稳定性（防破环） ：数据库表结构经常变动（比如加个字段、改个字段名）。如果你把 Domain 当接口返回对象，只要数据库加一个字段，所有调用你接口的前端 App 都得跟着改代码（因为序列化后多了一个不需要的字段）。而有了 DTO，你可以通过 @JsonProperty 或手动 set/get 组装，保证接口字段永远不变，哪怕数据库翻天覆地，前端也无需升级。
③ 结构聚合（性能与便捷性） ：前端的一个页面往往需要多张表的联合数据。比如前端需要“用户信息 + 订单总数 + 积分”。如果你只返回 Domain，前端需要调 3 个接口，发 3 次请求。但你可以在 Service 层查完 3 张表后，组装成一个完整的 DTO（比如 UserProfileDTO），一次返回给前端，大幅减少网络开销。

Domain 就像中央厨房的后厨食材库（包含整只鸡、未处理的生肉、秘制酱料配方）。这些东西很全，但绝不能直接端给客人。
DTO 就像端上餐桌的精美菜品（比如一盘宫保鸡丁）。它只是食材库的一部分组合，经过加工（业务处理），去掉了不能吃的部分（敏感信息），摆盘精致（结构符合前端展示需求）。

DTO 的组装逻辑写在 Service 层（业务层），由 Service 从多个 Mapper 查数据，然后 new UserDTO()，往里 set 值，再返回给 Controller。
Controller 层只接收 Service 返回的 DTO，直接通过 @ResponseBody 转为 JSON 返回给前端，Controller 绝不直接返回 Domain。

总结一句话：Domain 面向数据库（对内），DTO 面向用户（对外）。 分开了，后端代码可以随便重构优化，前端永远不知情，这才是正规军写法的精髓。

到此这篇关于Java中domain和dto区别小结的文章就介绍到这了,更多相关Java domain dto内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！