这样做的关键不是在Spring Data REST中有太多的事情-您可以轻松地使其在您的场景中工作-但要确保模型使关联的两端保持同步。
您在这里看到的问题是由于Spring Data REST基本上修改了的books属性而引起的AuthorEntity。那本身并不能反映的authors属性中的此更新BookEntity。这必须手动解决，这不是Spring Data REST构成的约束，而是JPA通常的工作方式。您将可以通过简单地手动调用设置器并尝试保留结果来重现错误的行为。
如果删除双向关联不是一种选择（请参阅下文，为什么我会推荐这样做），那么进行此工作的唯一方法是确保对关联的更改都反映在双方。通常，人们通过在添加BookEntity书籍时将作者手动添加到来解决此问题：
class AuthorEntity {
void add(BookEntity book) {
this.books.add(book);
if (!book.getAuthors().contains(this)) {
book.add(this);
}
}
}
BookEntity如果要确保也传播另一侧的更改，则也必须在另一侧添加附加的if子句。该if否则这两种方法将不断称自己基本上是必需的。
Spring Data REST默认情况下使用字段访问，因此实际上没有方法可以将该逻辑放入其中。一种选择是切换到属性访问并将逻辑放入设置器中。另一种选择是使用带有@PreUpdate/ 注释的方法，该方法@PrePersist在实体上进行迭代并确保修改在两侧均得到反映。
如您所见，这为域模型增加了很多复杂性。正如我昨天在Twitter上开玩笑说的：
双向关联的＃1规则：不要使用它们……:)
如果您尝试尽可能不使用双向关系，而是退回到存储库以获取构成关联背面的所有实体，通常可以简化此过程。
一个好的启发式方法是确定关联的哪一部分对您正在建模的领域而言确实是核心且至关重要的，它是考虑关联的哪一部分。在您的情况下，我认为对于没有作者写作的作者来说，这是完全可以的。另一方面，没有作者的书根本没有太大意义。因此，我将保留该authors属性，BookEntity但在上引入以下方法BookRepository：
interface BookRepository extends Repository<Book, Long> {
List<Book> findByAuthor(Author author);
}
是的，这需要以前可能已经调用过的所有客户端author.getBooks()现在可以使用存储库。但从积极的方面来说，您已经删除了域对象中的所有杂项，并在整个过程中从书本到作者都建立了明确的依赖方向。书籍取决于作者，但不取决于作者。
602392714
清零编程群