JPA管理依赖关系的方式让我疯狂。如果我有一个实体Parent并且我想要另一个实体Child在删除Parent时被清理，那么我似乎必须双向拥有硬编码依赖。这会对我如何布置包裹造成严重破坏。
例如，假设我有一个名为User的实体。后来，我想添加Facebook功能。所以我想为用户添加Facebook令牌和ID。我创建了一个Facebook包，以包含我所有的特定于Facebook的插件代码。我的FacebookInfo实体包含用户实体引用。但现在我有一个问题。我希望在删除用户时删除FacebookInfo记录。这迫使我向User添加一个FacebookInfo引用，创建一个双向关系。和BAM，现在我的“用户”和“facebook”包之间有一个循环。除了支持级联删除之外，我不需要UserIn中的FacebookInfo。理想情况下，我希望FacebookInfo实体类指定在用户时删除它。然后所有的依赖都是单向的。
大多数人在使用JPA时都会在包中循环依赖，或者有一种不错的方法可以避免这种情况吗？如果有一种特定于hibernate的方法来处理这个问题（不使用XML），我也可以这样做。感谢。
答案 0 :(得分：2)
使用JPA [？]
时，大多数人都会在包中循环依赖
根据我的经验：不仅在使用JPA时。这是使许多大型代码库如此可怕的众多因素之一。
有没有一种可靠的方法来避免这种情况？
基本思想是使用接口，我看到两个选项来应用它。一个使用JPA，但我不能保证它有效。其他或多或少独立于JPA。
JPA方式
不要将FacebookInfo引用返回到接口ExtraUserInfo，而是让FacebookInfo实现该接口（或抽象类）。 ExtraUserInfo将与用户位于同一个包中，因此所有周期都消失了。我不确定基于接口的这种映射是否可行，但如果它有效，它应该具有预期的效果。
JPA独立
您可以创建一种机制，在删除（或任何其他相关操作）之前，Listener获得通知。同样，Listener接口和整个机制将驻留在User包中（或更可能位于User包依赖的包中），而Listener的实际实现将驻留在UserInfo包中。根据您的体系结构，可能存在建立此类通知机制的各种位置。可能位于持久层中的存储库中。实际上我认为JPA本身支持这样的通知机制，因此这可能会变成另一种JPA基础解决方案。