多年的教训:根据DDD设计原则改变JPA/Hibernate的使用方式

我（lorenzo）最近一直在更新一些培训材料，思考JPA更好的教学方法和讨论方式。我一直在思考的一件事是我们通常是如何使用JPA？这里结合我所经历的（和观察到的）痛苦，应该如何改变传统使用方式？

JPA通常被视为一组注释（或XML文件），它们提供O/R（对象关系）映射信息。大多数开发人员认为他们知道和使用的映射注释越多，他们得到的好处就越多。但是在过去的几年里，与中小规模的巨石/单体/整体系统（大约有200张表/实体）的搏斗教会了我一些别的东西。

教训：

• 按ID引用实体（仅映射聚合中的实体关系）
• 不要让JPA窃取你的ID（尽可能避免@GeneratedValue）
• 使用特殊join来join不相关的实体

按标识符ID引用实体

仅映射DDD聚合中的实体关系。

传统 JPA或Hibernate教程（和培训）通常会涵盖所有可能的实体关系映射。在教学基本映射之后，许多映射将从简单的单向@manytone映射开始。然后继续双向@OneToMany和@ManyToOne。不幸的是，大多数情况下，他们没有明确指出，这种映射关系不是很好。因此，初学者在完成训练时往往会认为，不映射相关实体是错误的。他们错误地认为外键字段必须映射为相关实体。

@Entity
public class SomeEntity {
    // ...
    @ManyToOne private Country country;
    // ...
}
 
@Entity
public class Country {
    @Id private String id; // e.g. US, JP, CN, CA, GB, PH
    // ...
}

将上面@ManyToOne 应该改为@Column，将相关实体的主键映射为一个字段即可：

@Entity
public class SomeEntity {
    // ...
    @Column private String countryId;
    // ...
}
 
@Entity
public class Country {
    @Id private String id; // e.g. US, JP, CN, CA, GB, PH
    // ...
}

映射所有实体关系会增加了不必要的遍历的机会，这通常会导致不必要的内存消耗。这也会导致不必要的EntityManager操作级联。

如果您只处理少数几个实体/表，这可能并不多。但是当与几十个（如果不是几百个）实体一起工作时，它就变成了维护的噩梦。

何时映射相关实体？

仅当相关实体位于聚合中时才映射它们（在DDD中）。

聚合是领域驱动设计中的一种模式。DDD聚合是可以作为单个单元处理的域对象的集群。例如订单及其行项目，它们将是单独的对象，但将订单（及其行项目）视为单个聚合非常有用。

https://martinfowler.com/bliki/DDD_Aggregate.html

@Entity
public class Order {
    // ...
    @OneToMany(mappedBy = "order", ...) private List<OrderItem> items;
    // ...
}
 
@Entity
public class OrderItem {
    // ...
    @ManyToOne(optional = false) private Order order;
    // ...
}

更现代的聚合设计方法提倡在聚合之间进行更干净的分离。通过存储聚合根的ID（唯一标识符）而不是完整的引用来引用聚合根是一种很好的做法。

如果我们展开上面的简单订单示例，那么行项目（OrderItem类）不应该有到产品的@ManyToOne映射，相反，它应该只有产品的ID：

@Entity
public class Order {
    // ...
    @OneToMany(mappedBy = "order", ...) private List<OrderItem> items;
    // ...
}
 
@Entity
public class OrderItem {
    // ...
    @ManyToOne(optional = false) private Order order;
    // @ManyToOne private Product product; // <-- Avoid this!
    @Column private ... productId;
    // ...
}

但是…如果产品（聚合根实体）的@Id字段映射为@GeneratedValue呢？我们是否必须先持久化/flush刷新，然后使用生成的ID值？

那么，join呢？我们还能在JPA中Join这些实体吗？

别让JPA偷走你的标识

使用@GeneratedValue最初可能会使映射简单易用。但是，当您开始通过ID（而不是通过映射关系）引用其他实体时，这将成为一个挑战。

如果产品（聚合根实体）的@Id字段映射为@GeneratedValue，则调用getId（）可能返回null。当它返回null时，行项目（OrderItem类）将无法引用它！

在所有实体都有一个非空Id字段的环境中，按Id引用任何实体都会变得更容易。此外，始终具有非空的Id字段，使得equals（Object）和hashCode（）更容易实现。

因为所有Id字段都显式初始化，所以所有（聚合根）实体都有一个接受Id字段值的公共构造函数。可以添加一个受保护的no-args构造函数来让JPA满意。

@Entity
public class Order {
    @Id private Long id;
    // ...
    public Order(Long id) {
        // ...
        this.id = id;
    }
    public Long getId() { return id; }
    // ...
    protected Order() { /* as required by ORM/JPA */ }
}

在写这篇文章的时候，我发现了James Brundege的一篇文章（2006年发布的）， Don't Let Hibernate Steal Your Identity （感谢Wayback Machine），他说，不要让Hibernate管理你的Id。但愿我早点听他的劝告。

但要小心！当使用Spring Data JPA save（）保存一个在其@Id字段上不使用@GeneratedValue的实体时，在预期的INSERT之前会发出一个不必要的SQL SELECT。这是由于SimpleJpaRepository的save（）方法（如下所示）。它依赖于@Id字段（非空值）的存在来确定是调用persist（Object）还是merge（Object）。

public class SimpleJpaRepository // ...
    @Override
    public <S extends T> save(S entity) {
        // ...
        if (entityInformation.isNew(entity)) {
            em.persist(entity);
            return entity;
        } else {
            return em.merge(entity);
        }
    }
}

精明的读者会注意到，如果@Id字段从不为null，save（）方法将始终调用merge（）。这会导致不必要的SQL SELECT（在预期的INSERT之前）。

幸运的是，解决方法很简单-实现 Persistable<ID>.

@MappedSuperclass
public abstract class BaseEntity<ID> implements Persistable<ID> {
    @Transient
    private boolean persisted = false;
    @Override
    public boolean isNew() {
        return !persisted;
    }
    @PostPersist
    @PostLoad
    protected void setPersisted() {
        this.persisted = true;
    }
}
以上还意味着对实体的所有更新都必须首先将现有实体加载到持久性上下文中，然后将更改应用到托管实体。

使用特殊Join连接来join不相关的实体

那么，连接join呢？既然我们通过ID引用了其他实体，那么如何在JPA中连接join不相关的实体呢？

在jpa2.2版本中，不相关的实体不能连接。但是，我无法确认这是否已经成为3.0版的标准，在3.0版中，所有javax.persistence引用都被重命名为jakarta.persistence。

给定OrderItem实体，缺少@manytone映射会导致它无法与产品实体联接。

@Entity
public class Order {
    // ...
}
 
@Entity
public class OrderItem {
    // ...
    @ManyToOne(optional = false) private Order order;
    @Column private ... productId;
    // ...
}

值得庆幸的是，Hibernate 5.1.0+（2016年发布）和EclipseLink 2.4.0+（2012年发布）一直在支持无关实体的连接。这些连接也称为特殊连接 ad-hoc joins。

SELECT o
  FROM Order o
  JOIN o.items oi
  JOIN Product p ON (p.id = oi.productId) -- supported in Hibernate and EclipseLink

另外，这也是一个API问题（支持两个根实体的JOIN/ON）。我真的希望它能很快成为一种标准。