在我之前的博文中，我介绍了如何设置和使用 Spring Data JDBC。我还描述了使 Spring Data JDBC 比 JPA 更易于理解的前提。一旦您考虑引用，这就会变得很有趣。作为第一个示例，请考虑以下领域模型

class PurchaseOrder {

  private @Id Long id;
  private String shippingAddress;
  private Set<OrderItem> items = new HashSet<>();

  void addItem(int quantity, String product) {
    items.add(createOrderItem(quantity, product));
  }

  private OrderItem createOrderItem(int quantity, String product) {

    OrderItem item = new OrderItem();
    item.product = product;
    item.quantity = quantity;
    return item;
  }
}

class OrderItem {
  int quantity;
  String product;
}

此外，请考虑如下定义的存储库

interface OrderRepository extends CrudRepository<PurchaseOrder, Long> {

  @Query("select count(*) from order_item")
  int countItems();
}

如果您创建了一个包含项目的订单，您可能希望它全部持久化。这正是发生的事情。

@Autowired OrderRepository repository;

@Test
public void createUpdateDeleteOrder() {

  PurchaseOrder order = new PurchaseOrder();
  order.addItem(4, "Captain Future Comet Lego set");
  order.addItem(2, "Cute blue angler fish plush toy");

  PurchaseOrder saved = repository.save(order);

  assertThat(repository.count()).isEqualTo(1);
  assertThat(repository.countItems()).isEqualTo(2);
  …

此外，如果您删除了PurchaseOrder，其所有项目也应该被删除。同样，情况就是这样。

  …
  repository.delete(saved);

  assertThat(repository.count()).isEqualTo(0);
  assertThat(repository.countItems()).isEqualTo(0);
}

但是，如果我们考虑一个语法相同但语义不同的关系呢？

class Book {
  // …
  Set<Author> authors = new HashSet<>();
}

当一本书绝版时，您会删除它。所有作者都消失了。当然不是您想要的结果，因为一些作者可能还写了其他书。现在，这没有意义。或者有意义吗？我认为有意义。

为了理解为什么这有意义，我们需要退一步，看看存储库实际上持久化了什么。这与一个反复出现的问题密切相关：在 JPA 中是否应该为每个表创建一个存储库？

并且正确且权威的答案是“否”。存储库持久化和加载聚合。聚合是一组形成一个单元的对象，这些对象应始终保持一致。此外，它应该始终一起持久化（和加载）。它有一个单一的对象，称为聚合根，它是唯一允许接触或引用聚合内部的对象。聚合根是传递给存储库以持久化聚合的对象。

这就引出了一个问题：Spring Data JDBC 如何确定哪些是聚合的一部分，哪些不是？答案非常简单：您可以通过遵循非瞬态引用从聚合根到达的所有内容都是聚合的一部分。

考虑到这一点，OrderRepository的行为就非常合理了。OrderItem实例是聚合的一部分，因此会被删除。相反，Author实例不是Book聚合的一部分，因此不应被删除。因此，它们根本不应该从Book类中引用。

问题解决了。好吧，……不完全是。我们仍然需要存储和访问有关Book和Author之间关系的信息。答案同样可以在领域驱动设计 (DDD) 中找到，它建议使用 ID 而不是直接引用。这适用于所有类型的多对多关系。

如果多个聚合引用同一个实体，则该实体不能是引用它的这些聚合的一部分，因为它只能是恰好一个聚合的一部分。因此，任何多对一和多对多关系都必须通过仅引用 id 来建模。

如果您应用此方法，则可以实现多项功能

1. 您可以清楚地表示聚合的边界。

2. 您还可以完全解耦（至少在应用程序的领域模型中）所涉及的两个聚合。

3. 这种分离可以在数据库中以不同的方式表示

   1. 保留数据库的正常方式，包括所有外键。这意味着您必须确保以正确的顺序创建和持久化聚合。

   2. 使用延迟约束，这些约束仅在事务的提交阶段进行检查。这可能会提高吞吐量。它还编纂了最终一致性的一个版本，其中“最终”与事务结束相关联。这也允许引用不存在的聚合，只要它仅在事务期间发生即可。这对于避免大量的基础设施代码以仅满足外键和非空约束可能很有用。

   3. 完全删除外键，允许真正的最终一致性。

   4. 将引用的聚合持久化到不同的数据库中，甚至可能是 NoSQL 存储。

无论您将分离进行到何种程度，即使 Spring Data JDBC 强制执行的最小分离也能鼓励应用程序的模块化。此外，如果您尝试过迁移一个真正庞大的 10 年历史的应用程序，您就会明白这有多么宝贵。

使用 Spring Data JDBC，您可以像这样建模多对多关系

class Book {

  private @Id Long id;
  private String title;
  private Set<AuthorRef> authors = new HashSet<>();

  public void addAuthor(Author author) {
    authors.add(createAuthorRef(author));
  }

  private AuthorRef createAuthorRef(Author author) {

    Assert.notNull(author, "Author must not be null");
    Assert.notNull(author.id, "Author id, must not be null");

    AuthorRef authorRef = new AuthorRef();
    authorRef.author = author.id;
    return authorRef;
  }
}

@Table("Book_Author")
class AuthorRef {
  Long author;
}

class Author {
  @Id Long id;
  String name;
}

请注意额外的类（AuthorRef），它表示 Book 聚合对作者的了解。它可能包含关于作者的其他聚合信息，然后这些信息实际上会在数据库中重复。考虑到作者数据库可能与书籍数据库完全不同，这使得很多事情成为可能。

另外，请注意作者集是一个私有字段，并且AuthorRef实例的实例化发生在私有方法中。因此，聚合外部的任何内容都无法直接访问它。这并不是 Spring Data JDBC 所必需的，但它是 DDD 所鼓励的。领域将像这样使用

@Test
public void booksAndAuthors() {

  Author author = new Author();
  author.name = "Greg L. Turnquist";

  author = authors.save(author);

  Book book = new Book();
  book.title = "Spring Boot";
  book.addAuthor(author);

  books.save(book);

  books.deleteAll();

  assertThat(authors.count()).isEqualTo(1);
}

总结一下：Spring Data JDBC 不支持多对一或多对多关系。为了建模这些关系，请使用 ID。这鼓励了领域模型的干净模块化。它还消除了如果此类映射成为可能，则必须解决和学习推理的一整类问题。

同样，避免双向依赖。聚合内部的引用从聚合根指向元素。聚合之间的引用在一个方向上由 ID 表示。此外，如果您需要导航反向方向，请在存储库中使用查询方法。这使得哪个聚合负责维护引用变得一目了然。

以下是示例使用的数据库结构。

Purchase_Order (
  id
  shipping_address
)

Order_Item (
  purchase_order
  quantity
  product
);

Book (
  id
  title
)

Author (
  id
  name
)

Book_Author (
  book
  author
)