改进 JPA 多态关联的设计答案

【问题标题】：Improving the design of a JPA polymorphic association改进 JPA 多态关联的设计
【发布时间】：2017-06-09 10:41:09
【问题描述】：

我有以下 JPA 实体层次结构：

登录到应用程序后，用户在会话中有一个UserAccount 的实例；然后根据与UserAccount（Admin、Business 或Family）关联的组织的具体类型，向用户显示不同的仪表板/屏幕，例如如果用户是Business，则显示该业务的仪表板。

我对这种设计的担忧是，我必须在每次用户登录时进行instanceof 检查，以便我知道要显示哪种类型的仪表板。我还可以通过在UserAccount 中拥有一个属性来避免instanceof 检查，例如organizationType（它会采用三个值之一），但是会有多余的信息。

有没有办法改进我的设计？如果有怎么办？

【问题讨论】：

本质上是数据包的继承层次结构（即贫血的域模型）对我来说总是一个坏主意，这就是为什么我倾向于谨慎使用它们。三种组织类型的数据需求是否存在本质区别？如果没有，我会认真考虑展平结构并改用organizationType 属性。如果存在本质差异，并且Organization 实体的客户端 不知道他们正在与之交互的确切类，则您将不得不在some处使用instanceof > 无论如何都要点。
或者，如果您真的想避免使用instanceof，例如，您可以使用访客模式，该模式会为具体的@987654338 构建适当的Dashboard @ 类型（如果你问我，FTW）。如果有很多操作可以使用Organization，但需要知道具体的类型，也可以以Visitors的形式实现

标签： jpa polymorphic-associations

【解决方案1】：

贪婪并获得两者，没有冗余。

根据继承策略，您可能已经拥有organizationType 信息，您可以免费公开它。

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "DTYPE")
public abstract class AbstractOrganization implements Serializable
{
    @Id
    protected Long id;

    @Column(name = "DTYPE", insertable = false, updatable = false)
    protected String organizationType;

    ...

}

这同样适用于JOINED 策略。

不要实现setOrganizationType 方法。

由于鉴别器是必需来模拟带有表的层次结构（TABLE_PER_CLASS 策略除外），因此没有冗余，JPA 提供程序将为您处理此属性。 p>

【讨论】：