本文探讨在Java应用中，当需要根据某个字段对数据进行分组，但在最终的API响应中希望从每个分组项中剔除该分组字段时，可采用的两种主要策略。我们将详细介绍使用`@JsonIgnore`注解的简单方法及其局限性，以及通过创建专用响应DTO并结合`Collectors.mapping`进行二次转换的更灵活、更推荐的解决方案，以实现精确的API数据控制。
在构建API服务时，我们经常需要从数据源获取一组记录，根据其中某个属性进行分组，然后将分组后的数据作为JSON响应返回。然而，一个常见的需求是，用于分组的属性（例如部门名称）在作为Map的键值出现后，就不再希望它出现在每个分组内部的记录对象中，以避免数据冗余或简化响应结构。
假设我们有以下员工记录接口：
public interface EmployeesRecord {
String getName();
String getDepartment();
String getEmail();
}以及一个用于将这些记录按部门分组的DTO：
立即学习“Java免费学习笔记（深入）”；
import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;
public record EmployeesDto(Map<String, List<EmployeesRecord>> employeesRecordList) {
public static EmployeesDto from(List<EmployeesRecord> data) {
Map<String, List<EmployeesRecord>> mappedEmployees =
data.stream().collect(Collectors.groupingBy(EmployeesRecord::getDepartment));
return new EmployeesDto(mappedEmployees);
}
}当前的响应会包含每个员工记录中的department字段，如下所示：
{
"employeesRecordList": {
"finance": [
{
"name": "Jerry Doe",
"department": "finance",
"email": "jerry.doe@example.com"
},
// ...
],
"engineering": [
{
"name": "Joe Doe",
"department": "engineering",
"email": "joe.doe@example.com"
},
// ...
]
}
}而我们的目标是移除每个员工对象中的department字段，使其响应结构更简洁：
{
"employeesRecordList": {
"finance": [
{
"name": "Jerry Doe",
"email": "jerry.doe@example.com"
},
// ...
],
"engineering": [
{
"name": "Joe Doe",
"email": "joe.doe@example.com"
},
// ...
]
}
}为了实现这一目标，我们可以采用以下两种主要策略。
策略一：使用@JsonIgnore注解
最直接且简单的解决方案是利用Jackson（或其他JSON序列化库）提供的@JsonIgnore注解。通过在EmployeesRecord接口的getDepartment()方法上添加此注解，可以在JSON序列化时自动忽略该字段。
实现方式：
假设EmployeesRecord是一个具体的类或记录，或者您正在处理其实现类，您可以直接在getDepartment()方法上添加@JsonIgnore。如果EmployeesRecord是一个接口，通常需要在其实现类上进行注解。
import com.fasterxml.jackson.annotation.JsonIgnore;
// 假设这是一个具体的Record或POJO
public record EmployeeDataRecord(String name, String department, String email) implements EmployeesRecord {
@Override
public String getName() {
return name;
}
@Override
@JsonIgnore // 在序列化时忽略此字段
public String getDepartment() {
return department;
}
@Override
public String getEmail() {
return email;
}
}优点：
- 简单快捷： 实现成本极低，只需添加一个注解。
缺点：
- 缺乏灵活性： @JsonIgnore会全局性地隐藏该字段，这意味着无论在何处使用EmployeeDataRecord进行JSON序列化，department字段都将不会出现。如果您的应用程序在其他地方需要序列化department字段，这种方法将不适用。
- 修改源数据模型： 它修改了原始数据模型的序列化行为，可能影响到其他不希望此字段被忽略的场景。
策略二：创建专用响应DTO并进行二次映射
为了实现更精细的控制和更好的关注点分离，推荐的方法是创建一个专门用于API响应的DTO，其中只包含所需的字段。然后，在分组操作之后，将原始记录映射到这个新的DTO实例。
实现方式：
-
定义一个精简的响应DTO： 创建一个新的Record或类，只包含name和email字段。
// 用于API响应的精简DTO public record EmployeeDetailResponse(String name, String email) { // 构造函数，方便从EmployeesRecord转换 public EmployeeDetailResponse(EmployeesRecord record) { this(record.getName(), record.getEmail()); } } -
修改EmployeesDto以使用新的DTO类型： 更新EmployeesDto中的Map值类型，使其存储List<EmployeeDetailResponse>而不是List<EmployeesRecord>。
import java.util.List; import java.util.Map; import java.util.stream.Collectors; // 注意：这里的employeesRecordList类型已更新 public record EmployeesDto(Map<String, List<EmployeeDetailResponse>> employeesRecordList) { public static EmployeesDto from(List<EmployeesRecord> data) { Map<String, List<EmployeeDetailResponse>> mappedEmployees = data.stream().collect( // 首先按部门分组 Collectors.groupingBy( EmployeesRecord::getDepartment, // 然后对每个分组内的元素进行映射，转换为EmployeeDetailResponse Collectors.mapping(EmployeeDetailResponse::new, Collectors.toList()) ) ); return new EmployeesDto(mappedEmployees); } }
优点：
- 高度灵活： 原始的EmployeesRecord保持不变，其序列化行为不受影响。您可以为不同的API端点创建不同的响应DTO，实现精确的数据暴露。
- 关注点分离： 将数据模型（EmployeesRecord）与API响应模型（EmployeeDetailResponse）明确分离，提高了代码的可维护性和可读性。
- 避免数据冗余： 响应中只包含客户端真正需要的数据，减少了网络传输量。
缺点：
- 代码量略增： 需要额外定义一个DTO类，并修改Stream的收集逻辑，相对@JsonIgnore稍显复杂。
选择合适的策略
- 如果department字段在任何JSON序列化场景中都不需要，并且您追求最快的实现速度， 那么策略一（@JsonIgnore） 是一个简单有效的选择。但请务必确认这种全局性影响是可接受的。
- 如果department字段在其他场景中可能需要序列化，或者您希望实现更清晰的API设计和更好的数据封装， 那么策略二（创建专用响应DTO并进行二次映射） 是更专业、更健壮的解决方案。它提供了最大的灵活性和控制力，是构建可维护、可演进API的推荐做法。
在实际开发中，通常推荐使用策略二。它符合API设计中“按需提供数据”的原则，并有助于保持数据模型的纯净性。
