如何使我的 Java 模型独立于 JPA 实体，同时避免代码重复 [关闭]

Question

我的 Java 项目使用 JPA 作为持久性解决方案。随着我阅读越来越多的 JPA 教程和指南，我发现（可能是为了简单起见）每个作者都使用实体类作为他们的模型类。就代码可扩展性和可维护性而言，这显然是一个糟糕的设计选择：更改持久性解决方案的决定将意味着对整个模型进行完全重构（或重写）。

事情是，重写与每个实体类对应的模型类感觉不合适且不优雅，因为如果不是 JPA 注释，所有这些都将与相应的实体类相同（在我个人的情况下）。将它们写为实体类实现的接口也感觉不对，无论是因为当我可能需要使用不对应于实体的类扩展模型时出现潜在的不一致，还是因为在 Java 中泛型用于表示 @OneToMany 和 @ManyToMany 关系不（也不应该）与抽象接口协变。

我现在将发布一些代码来说明我的担忧：

package com.depvin.pps.orm;

import javax.persistence.*;


@Entity
@DiscriminatorValue("E")
public class EmployeeEntity extends UserEntity {
    @ManyToMany
    @JoinTable(name = "EmployeeProject",
            joinColumns = @JoinColumn(name = "employee"),
            inverseJoinColumns = @JoinColumn(name = "project"))
    List<ProjectEntity> projects;

    public EmployeeEntity(String username) {
        super(username);
    }

    public List<ProjectEntity> getProjects() {
        return projects;
    }
}

考虑到我上面提的问题，对应的模型类/接口应该如何实现？

Answer 1

从我的角度来看，这是一个很好的设计。一个实体是一个模型类。它是（或应该是）业务对象的体现，它是领域模型的一部分。

你是对的，你应该不为持久化 API 构建你的模型。但我在上面的例子中没有看到你这样做的地方。除了注释，但那些不构成您的模型，它只是元数据。您甚至可以将其放入一个额外的映射文件中，并拥有直接的模型类。

如果您的意思是从现有数据库创建模型类并且生成的类不表达业务模型，那么您应该考虑您的数据库模型。

而且您可以随时更改持久性解决方案，我不明白为什么您需要在这里坚持使用 JPA。例如，从任何带有一些注释的实体类创建 JSON 将非常容易。

最后一件事：如果您没有在@OneToMany 中定义targetEntity 属性，JPA 仅使用集合的泛型类型。

Answer 2

JPA-Objects的注解是对象-关系映射，所以JPA-Objects是对象-关系映射的一部分。

您是对的，您经常将 JPA 对象视为项目架构中的模型对象。我并不是说这种解决方案在任何情况下都足够糟糕。但是如果你想清楚你应该把对象关系映射层和业务层这两个方面分开。如果你这样做了，根据 SRP，你可能有技术冗余但没有语义冗余。 SRP 说一个代码片段应该只为一个目的而改变。如果映射发生变化，那么 ORM 层就是正确的位置。如果业务规则发生变化，请转到模型层。

当然，您可能有代码在层之间传输数据。 “字符串名称”可能出现在 JPA 对象和模型对象中。但它根本不是映射，它的缓存。缓存会产生让您不舒服的冗余。如果您不想缓存，请从模型层委托给 JPA 层。但请保持业务逻辑与 JPA 层分离。

毕竟：如果您有一个小型项目，那么您不会遇到仅使用 JPAObject 解决方案的任何实际问题。这一切都伴随着大小。然后我推荐 BusinessObject -> DAO -> JPAObject 结构。