如何实现通用Spring Service查询实体并仅返回指定字段

我实现了一个通过EntityManager根据实体名称获取实体的Service，代码如下：

获取实体的Service方法 #

public Object getEntity(long resourceId, String resource) throws EntityNotFoundException {
    try{
        Class<?> cls = Class.forName("com.example.package.models." + resource);
        Object resourceOpt = findById(cls, resourceId);

        if(resourceOpt == null){
            throw new EntityNotFoundException("Resource " + resource + " could not be found with id: " + resourceId);
        }

        return resourceOpt;
    }catch (ClassNotFoundException ex){
        throw new EntityNotFoundException("Resource " + resource + " could not be found with id: " + resourceId);
    }
}

findById方法实现 #

public <T, ID> T findById(Class<T> type, ID id) {
    return entityManager.find(type, id);
}

功能运行正常，但获取User实体时，返回结果包含所有字段（比如敏感的password）：

{
    "id": 1,
    "firstname": "name",
    "lastname": "surname",
    "email": "email@email.com",
    "password": "password",
    "role": "USER",
    "enabled": true,
    "username": "email@email.com",
    "authorities": [
        {
            "authority": "USER"
        }
    ],
    "accountNonLocked": true,
    "credentialsNonExpired": true,
    "accountNonExpired": true
}

想知道如何实现仅返回实体的部分字段？应该用DTO还是JsonField相关注解？

两种方案都可行，对应不同场景，具体说明如下：

方案一：使用JSON序列化注解（如@JsonIgnore） #

如果只是固定隐藏某些敏感字段（比如password），直接在实体类的对应字段上加序列化注解是最快捷的方式：

// 在User实体的password字段上添加注解
@JsonIgnore
private String password;

优劣总结 #

• 优点：实现简单，无需额外创建类；适合全局统一隐藏字段的场景。
• 缺点：灵活性差——如果某些接口需要返回该字段（比如用户修改密码接口），注解方式无法动态切换；另外你的Service是通用型的，若其他实体也有类似需求，需要逐个实体添加注解。

方案二：使用DTO（数据传输对象） #

如果需要按需返回不同字段组合，或者想让API返回层和实体层解耦，DTO是更规范的做法：

1. 创建UserDTO类，只定义需要对外返回的字段：

public class UserDTO {
    private Long id;
    private String firstname;
    private String lastname;
    private String email;
    private String role;
    // 按需添加其他需要返回的字段
    // 生成getter、setter，或用Lombok简化代码
}

2. 实现实体到DTO的转换逻辑（可以用MapStruct、ModelMapper等工具简化，也可手动转换）：

// 手动转换示例
private UserDTO convertToUserDTO(User user) {
    UserDTO dto = new UserDTO();
    dto.setId(user.getId());
    dto.setFirstname(user.getFirstname());
    dto.setLastname(user.getLastname());
    dto.setEmail(user.getEmail());
    dto.setRole(user.getRole());
    return dto;
}

3. 修改getEntity方法，针对User实体返回DTO，其他实体可按需处理：

public Object getEntity(long resourceId, String resource) throws EntityNotFoundException {
    try{
        Class<?> cls = Class.forName("com.example.package.models." + resource);
        Object entity = findById(cls, resourceId);

        if(entity == null){
            throw new EntityNotFoundException("Resource " + resource + " could not be found with id: " + resourceId);
        }

        // 针对User实体转换为DTO
        if(entity instanceof User) {
            return convertToUserDTO((User) entity);
        }
        // 其他实体若需DTO，可继续添加判断逻辑
        return entity;
    }catch (ClassNotFoundException ex){
        throw new EntityNotFoundException("Resource " + resource + " could not be found with id: " + resourceId);
    }
}

优劣总结 #

• 优点：高度灵活，可根据不同接口需求定义不同DTO；实体层和API返回层解耦，避免实体字段变更直接影响API响应；适合复杂场景或需要多字段组合返回的情况。
• 缺点：需要额外创建DTO类，增加少量代码量（但转换工具可大幅简化这部分工作）。

方案选择建议 #

• 若只是固定隐藏敏感字段，用JSON注解快速解决；
• 若需要灵活控制返回字段、或者项目有规范的分层要求，优先选择DTO。

内容的提问来源于stack exchange，提问作者Federico Arona