4

JPA 管理依赖项的方式让我抓狂。如果我有一个实体 Parent 并且我希望在删除 Parent 时清理另一个实体 Child ，那么似乎我必须有一个硬编码的依赖关系。这对我如何布局我的包裹造成了严重破坏。

例如，假设我有一个名为 User 的实体。稍后，我想添加 Facebook 功能。所以我想为用户添加 Facebook 令牌和 id。我创建了一个 Facebook 包来包含我所有的 Facebook 特定插件代码。我的 FacebookInfo 实体包含用户实体引用。但现在我有一个问题。我想在删除用户时删除 FacebookInfo 记录。这迫使我向创建双向关系的用户添加 FacebookInfo 引用。和 BAM，现在我的“用户”和“脸书”包之间有一个循环。除了支持级联删除之外，我不需要用户中的 FacebookInfo。理想情况下，我希望 FacebookInfo 实体类指定它要在用户被删除时被删除。然后所有依赖项都以一种方式进行。

大多数人在使用 JPA 时是否会强调包中的循环依赖关系，或者是否有一种体面的方法来避免这种情况？如果有一种特定于休眠的方法来处理这个问题（不使用 XML），我也可以这样做。谢谢。

4

1 回答 1

2

大多数人在使用 JPA 时是否会强调包中的循环依赖关系[？]

以我的经验：不仅在使用 JPA 时。这是使许多大型代码库如此可怕的众多原因之一。

有没有一种体面的方法来避免这种情况？

基本思想是使用接口，我看到了两个应用它的选项。一个使用 JPA，但我不能保证它有效。另一个或多或少独立于JPA。

JPA 方式

而不是引用回FacebookInfo引用回接口ExtraUserInfo，然后让FacebookInfo实现该接口（或抽象类）。ExtraUserInfo将与用户生活在同一个包中，所以所有周期都消失了。我不确定这种基于接口的映射是否可行，但如果可行，它应该会产生预期的效果。

JPA 独立

您可以创建一种机制，在删除（或任何其他相关操作）之前Listener通知 a。同样，Listener接口和整个机制将驻留在User包中（或更可能在包所User依赖的包中），而实际实现Listener将驻留在UserInfo包中。根据您的体系结构，可能有很多地方可以建立这种通知机制。可能在位于持久层的存储库中。实际上，我认为 JPA 本身就支持这种通知机制，因此这可能会变成另一种 JPA 基础解决方案。

于 2013-07-24T18:17:16.340 回答