OOP开发读写表API是否需定义不同对象及主键处理问题

你当前遇到的问题本质是混淆了持久化实体在不同API场景下的序列化规则，你预设的「读写接口必须共用同一对象」的前提完全可以实现，不需要采用你提到的两种有缺陷的方案。

你提到的两种方案存在明确的设计缺陷：

• 将id设置为Optional类型：Optional的设计定位是方法返回值的空语义标记，不适合作为实体字段类型，主流ORM框架（MyBatis、JPA等）对这类字段的兼容存在隐性问题，同时也无法明确区分「创建场景id禁止传入」和「查询场景id必然存在」的语义，会让后续业务代码充斥不必要的空判断。
• 定义Request/Response类继承Person：继承是层级间的强耦合关联，后续对Person实体的任何字段修改都会直接同步到API层，无法实现字段粒度的暴露控制，极易出现内部字段意外对外泄露的问题，属于典型的坏实践。

首选方案：使用Jackson JSON视图实现同对象不同场景序列化 #

这是Spring生态下专门解决这类「同一对象在不同接口序列化规则不同」场景的标准方案，零额外类冗余，完全满足你共用Person对象的要求：

1. 先定义视图标记接口，用来区分不同的序列化场景：

public class JsonViews {
    // 创建操作的视图：不处理id字段
    public interface Create {}
    // 查询操作的视图：包含id字段
    public interface Query extends Create {}
}

2. 给Person实体的主键字段添加视图注解，标记该字段仅在查询视图下生效：

public class Person {
    // 仅Query视图下才会序列化/反序列化id字段
    @JsonView(JsonViews.Query.class)
    private Integer id; // 数据库自增主键
    private String name;
    private Integer houseId;
    private Integer age;
    // 省略getter、setter方法
}

3. 给控制器接口方法添加对应的视图注解即可生效：

@RestController
public class TestController {
    // 查询接口绑定Query视图：返回结果会正常序列化id字段
    @JsonView(JsonViews.Query.class)
    @RequestMapping("/")
    public List<Person> fetchAll() {
        return personDao.findAll();
    }

    // 创建接口绑定Create视图：反序列化请求体时会直接忽略客户端传入的id字段
    @PostMapping(value = "/createPerson")
    public void createPerson(@JsonView(JsonViews.Create.class) @RequestBody Person person) {
        personDao.insertPerson(person);
    }
}

• 该方案的效果：调用创建接口时，就算客户端主动在请求体里传id参数，也会被序列化层直接忽略，不会进入业务逻辑；调用查询接口时，返回结果会正常携带id字段，完全符合你的需求。

可选增强：搭配分组校验强化语义 #

如果需要更严谨的参数校验，避免客户端非法传参，可以搭配Jakarta Validation的分组校验能力，给id字段添加场景化校验规则：

public class Person {
    // 创建场景下id必须为空，传入则直接触发参数校验错误
    @Null(groups = ValidationGroups.Create.class, message = "创建人员时请勿传入id")
    // 查询场景下id不能为空
    @NotNull(groups = ValidationGroups.Query.class, message = "人员信息缺失主键id")
    @JsonView(JsonViews.Query.class)
    private Integer id;

    // 其他字段可以按场景配置校验规则
    @NotBlank(groups = {ValidationGroups.Create.class, ValidationGroups.Query.class}, message = "姓名不能为空")
    private String name;
    
    private Integer houseId;
    private Integer age;
    // 省略getter、setter
}

在控制器方法上通过@Validated注解指定对应校验分组即可，和JSON视图搭配使用时体验更好。

补充说明：如果后续业务迭代中，API的出入参字段和数据库实体的差异越来越大（比如查询时需要返回关联的房屋名称，而非仅返回houseId），再考虑单独定义DTO类即可，当前场景下JSON视图是成本最低、最贴合需求的实现方式。

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