Java Stream分组后从响应对象中移除分组字段的策略

本文探讨在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> employeesRecordList) {

    public static EmployeesDto from(List data) {
        Map> 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序列化时自动忽略该字段。

实现方式：

Veggie AI

Veggie AI 是一款利用AI技术生成可控视频的在线工具

下载

假设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实例。

实现方式：

1. 定义一个精简的响应DTO： 创建一个新的Record或类，只包含name和email字段。

   // 用于API响应的精简DTO
   public record EmployeeDetailResponse(String name, String email) {
       // 构造函数，方便从EmployeesRecord转换
       public EmployeeDetailResponse(EmployeesRecord record) {
           this(record.getName(), record.getEmail());
       }
   }

2. 修改EmployeesDto以使用新的DTO类型： 更新EmployeesDto中的Map值类型，使其存储List而不是List。

   import java.util.List;
   import java.util.Map;
   import java.util.stream.Collectors;
   
   // 注意：这里的employeesRecordList类型已更新
   public record EmployeesDto(Map> employeesRecordList) {
   
       public static EmployeesDto from(List data) {
           Map> 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设计中“按需提供数据”的原则，并有助于保持数据模型的纯净性。