JPA管理依赖关系的方式让我疯狂.如果我有一个实体Parent并且我想要另一个实体Child在删除Parent时被清理,那么我似乎必须双向拥有硬编码依赖.这会对我如何布置包裹造成严重破坏.

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

大多数人在使用JPA时都会在包中循环依赖,或者有一种不错的方法可以避免这种情况吗？如果有一种特定于hibernate的方法来处理这个问题(不使用XML),我也可以这样做.谢谢.

最佳答案

Do most people punt on cyclic dependencies in packages when using JPA[?]

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

Is there a decent way to avoid this?

基本的想法是使用接口,我看到两个选项来应用它.一个使用JPA,但我不能保证它有效.其他或多或少独立于JPA.

JPA的方式

而不是将FacebookInfo引用返回到ExtraUserInfo接口,然后让FacebookInfo实现该接口(或抽象类). ExtraUserInfo将与用户位于同一个包中,因此所有周期都消失了.我不确定基于接口的这种映射是否可行,但如果它有效,它应该具有所需的效果.

JPA独立

您可以创建一种机制,在该机制之前,监听器会在删除(或任何其他相关操作)之前获得通知. Listener接口和整个机制将再次驻留在User包中(或者更可能位于User包依赖的包中),而Listener的实际实现将驻留在UserInfo包中.根据您的体系结构,可能存在建立此类通知机制的各种位置.可能位于持久层中的存储库中.实际上我认为JPA本身支持这样的通知机制,因此这可能会变成另一种JPA基础解决方案.