本文探讨了在Spring Boot RESTful API中管理请求与响应数据传输对象（DTO）时常见的代码重复问题。针对传统分离式DTO设计带来的冗余，文章提出了一种通过统一核心业务DTO并使其继承通用元数据基类来有效消除重复的策略。这种方法利用了JSON序列化/反序列化机制的灵活性，简化了DTO结构，提升了代码的可维护性与简洁性，同时避免了多重继承和不必要的客户端数据封装。
理解DTO模式与代码冗余挑战
在构建restful api时，数据传输对象（dto）模式被广泛应用于封装http请求体和响应体的数据。它有助于将内部领域模型与外部api契约解耦，提供清晰的数据接口。然而，在实际开发中，我们经常会遇到请求dto和响应dto结构相似但又存在细微差异的情况。例如，响应dto通常会包含一些请求时不需要的额外元数据，如id、版本、创建时间、修改时间等。
传统上，为了区分请求和响应，开发者可能会创建独立的DTO类，例如 RequestUserDTO 和 ResponseUserDTO。当核心业务字段（如 firstName, lastName）在两者之间重复出现时，便产生了明显的代码冗余。
考虑以下常见的DTO结构示例：
// 响应DTO的基类，包含通用元数据public abstract class BaseResponseDTO { protected UUID id; protected Integer version; protected Date created; protected Date modified;}// 仅用于请求的用户DTOpublic class RequestUserDTO { private String firstName; private String lastName;}// 用于响应的用户DTO，继承自BaseResponseDTOpublic class ResponseUserDTO extends BaseResponseDTO { private String firstName; private String lastName;}
在这种设计中，firstName 和 lastName 字段在 RequestUserDTO 和 ResponseUserDTO 中重复定义，这不仅增加了维护成本，也使得代码不够DRY（Don’t Repeat Yourself）。
为了解决这种冗余，一些开发者可能会尝试以下方法：
多重继承： 期望 ResponseUserDTO 能够同时继承 BaseResponseDTO 和 RequestUserDTO。然而，Java 不支持类的多重继承，此路不通。
组合模式： 创建一个通用的 UserDTO 包含核心业务字段，然后让 RequestUserDTO 和 ResponseUserDTO 通过组合的方式引用它。
public abstract class BaseResponseDTO { protected UUID id; protected Integer version; protected Date created; protected Date modified;}public class UserDTO { // 通用业务数据部分 private String firstName; private String lastName;}public class RequestUserDTO { private UserDTO payload; // 客户端需要包装在payload中}public class ResponseUserDTO extends BaseResponseDTO { private UserDTO payload; // 客户端需要从payload中获取}
这种方法虽然解决了核心业务字段的重复定义，但引入了新的问题：客户端在发送请求时需要将数据包装在 payload 字段中（例如 {“payload”: {“firstName”: “…”, “lastName”: “…”}}），这增加了API的复杂性和客户端的使用负担。同时，从DTO结构上看，RequestUserDTO 和 ResponseUserDTO 仍然存在 payload 字段的重复定义。
优化方案：统一DTO与继承策略
解决上述代码冗余问题的更优方案是：将核心业务数据与通用元数据合并到一个统一的DTO中，并通过继承机制来处理响应所需的额外字段。
其核心思想是：
创建一个抽象的 BaseResponseDTO，包含所有响应中通用的元数据字段（如 id, version, created, modified）。创建一个统一的 UserDTO，它不仅包含 firstName 和 lastName 等业务字段，还直接继承 BaseResponseDTO。
这样，UserDTO 既可以作为请求体（Request Body）使用，也可以作为响应体（Response Body）使用。
// 响应DTO的基类，包含通用元数据public abstract class BaseResponseDTO { protected UUID id; protected Integer version; protected Date created; protected Date modified;}// 统一的用户DTO，既可用于请求也可用于响应public class UserDTO extends BaseResponseDTO { private String firstName; private String lastName; // Getters and Setters (省略) // 构造函数 (省略)}
这种方法的工作原理和优势：
请求时： 当 UserDTO 被用作请求体时，客户端只需发送业务字段（firstName, lastName）的数据。Spring Boot（或Jackson库）在反序列化时，会自动忽略请求JSON中未提供的 id, version 等 BaseResponseDTO 字段，而不会报错。
// 客户端发送的请求体示例{ "firstName": "John", "lastName": "Doe"}
后端接收到此JSON后，UserDTO 实例的 firstName 和 lastName 将被填充，而 id, version 等字段将保持其默认值（例如 null）。
响应时： 当 UserDTO 被用作响应体时，后端在返回数据前，会为 id, version, created, modified 等字段填充实际值，然后将其序列化为完整的JSON响应。
// 后端返回的响应体示例{ "id": "a1b2c3d4-e5f6-7890-1234-567890abcdef", "version": 1, "created": "2023-01-01T10:00:00Z", "modified": "2023-01-01T10:00:00Z", "firstName": "John", "lastName": "Doe"}
消除代码冗余： firstName 和 lastName 只定义了一次，极大地减少了重复代码。简化客户端交互： 客户端无需在请求中添加额外的包装字段（如 payload），直接发送业务数据即可。提高可维护性： 字段变更只需在一个地方修改，降低了出错的风险。
实现细节与注意事项
Jackson的默认行为： Spring Boot默认使用的Jackson库在JSON序列化和反序列化时，对于DTO中存在但JSON中缺失的字段，会默认忽略；对于JSON中存在但DTO中缺失的字段，也会默认忽略。这正是上述方案能够成立的基础。如果需要更严格的校验，例如不允许请求体中出现任何未定义的字段，可以通过Jackson的 DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES 配置来控制。
适用场景： 这种模式最适用于请求和响应的核心业务数据结构高度相似，且响应仅比请求多出一些通用元数据的情况。
不适用场景： 如果请求和响应的数据结构差异巨大，或者请求和响应的业务逻辑完全不同，那么强行使用一个统一的DTO可能会导致DTO过于臃肿或职责不清。在这种情况下，保持分离的DTO可能更为合适。
数据验证： 在Spring Boot中，通常会结合 @Valid 注解和JSR 303/380 Bean Validation API进行数据验证。在统一DTO的场景下，验证规则可以直接定义在 UserDTO 中。例如，可以对 firstName 和 lastName 添加 @NotBlank 等注解。
public class UserDTO extends BaseResponseDTO { @NotBlank(message = "First name cannot be blank") private String firstName; @NotBlank(message = "Last name cannot be blank") private String lastName; // ...}
在控制器方法中，使用 @RequestBody @Valid UserDTO userDTO 即可触发验证。
总结
通过采用统一的DTO并结合继承基类的方式来处理请求与响应，我们能够有效解决RESTful API中DTO代码冗余的问题。这种设计模式不仅简化了DTO结构，提高了代码的可维护性，也优化了客户端与API的交互体验。在设计API时，应根据实际业务场景权衡，选择最能体现简洁性、可读性和可维护性的DTO结构。
以上就是RESTful API设计：优化DTO结构以消除请求与响应中的代码冗余的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/142488.html
微信扫一扫 
支付宝扫一扫 
