Kotlin结合JPA开发Spring Boot实体的最佳实践咨询

你的配置与实体代码参考 #

build.gradle.kts 配置片段 #

plugins {
    id("org.springframework.boot") version "2.5.3"
    id("io.spring.dependency-management") version "1.0.11.RELEASE"
    kotlin("jvm") version "1.6.10"
    kotlin("plugin.spring") version "1.5.21"
    kotlin("plugin.jpa") version "1.5.21"
    kotlin("plugin.allopen") version "1.5.21"
}

allOpen {
    annotations("javax.persistence.Entity", "javax.persistence.MappedSuperclass", "javax.persistence.Embedabble")
}

UserEntity 实体代码 #

@Entity
@Table(name = "users")
class UserEntity(
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Int,
    @Column(name = "name")
    val name: String,
    @Column(name = "mail")
    val mail: String,
    @Column(name = "password")
    val password: String,
    @OneToOne
    @JoinColumn(name = "role_id", nullable = false)
    var role: RoleEntity
)

问题解答 #

1. JPA实体应使用class还是data class？ #

优先用普通class，不要用data class。原因如下：

• Data class会自动基于所有构造函数属性生成equals()、hashCode()和toString()，但JPA实体存在未持久化/已持久化的生命周期差异，且关联属性多为懒加载。自动生成的方法会触发懒加载关联的初始化，引发不必要的数据库查询，甚至出现循环引用问题。
• Data class的设计初衷是纯数据持有，而非支持JPA的持久化生命周期与子类扩展场景，即便有AllOpen插件支持开放类，也不符合实体的设计逻辑。

2. 是否需要重写equals()和hashCode()方法？ #

必须重写，否则会导致集合操作（如实体放入Set去重、List索引定位）出现异常，或缓存失效等问题。
重写核心原则是基于稳定的唯一标识：

• 如果实体有业务唯一键（比如你的mail字段，假设加了唯一约束），优先用业务键实现equals()和hashCode()，因为它在实体创建时就存在，不会像自增ID那样在持久化后才生成。
• 如果只有数据库生成的ID，要处理未持久化实体的情况：新创建的实体ID为0或null，此时可以结合System.identityHashCode()做临时标识，或约定未持久化实体不参与集合操作，避免equals结果变动导致的异常。

3. 为何仅转为data class时才出现IDE提示？ #

• 普通class默认不会自动生成equals()、hashCode()和toString()，IDE不会主动提醒缺失这些方法，只有你手动触发生成操作时才会提示。
• Data class会自动生成这些方法，而IDE内置了JPA实体的代码检查规则：它识别到自动生成的方法会包含懒加载关联属性，会触发不必要的查询或循环引用，因此给出“不推荐使用”的警告；同时，IDE又会检查到实体类通常需要这些方法来保证集合操作正确性，所以又会提示“生成equals/hashCode/toString”，两种提示因此并存。

4. 实体属性使用var还是val更合适？ #

• 优先用val表示不可变属性，符合Kotlin的不可变编程理念，也能避免意外修改实体状态。Kotlin JPA插件和AllOpen插件会通过反射机制，允许JPA在加载实体时为val属性赋值，无需手动添加setter。
• 只有当属性需要在业务逻辑中被修改时（比如用户更新昵称），才用var。
• 注意：对于自增ID属性，建议改成val id: Int? = null，因为新创建的实体还未被持久化，ID尚未生成，用可空类型更符合实际状态，JPA会在持久化后自动填充ID值。

5. 实体属性使用可空类型还是非可空类型更合适？ #

严格对齐数据库字段的可空性：

• 如果数据库字段设置为NOT NULL，属性用非可空类型（比如你的name、mail），同时配合@Column(nullable = false)注解，保持代码与数据库约束一致，避免空指针问题。
• 如果数据库字段允许为null，属性用可空类型（比如String?），不要强行用非可空类型加默认值，否则会掩盖数据的真实状态。
• 关联属性同理：比如你的role字段，数据库role_id是NOT NULL，所以用非可空的RoleEntity，配合@JoinColumn(nullable = false)，完全匹配约束。

内容的提问来源于stack exchange，提问作者Hasan Mhd Amin