java - 使用 JPA 继承作为获取不同方法实现的方式有意义吗？

Question

所以，我一直在努力熟悉 JPA 的继承功能，并且到目前为止我非常喜欢它们。我最近想到的一件事是，它们实际上可以用于除检索数据之外的其他用途。鉴于它可以根据鉴别器值获取子类，继承实际上是将配置字段转换为实现的便捷方法。在我的知识与经验比率处于“刚好足以危险/不足以始终意识到它区域”的阶段，我认为最好问问这是否是一个好主意。

以 PRODUCT 和 BILLTYPE 表为例。

Product:
int Id
int billtypeid

Billtype:
int id
varchar[15] description

Billtype 只是产品的一种计费策略(我们会说某些订单可能按重量计费，而其他订单可能仅按箱计费)。每种账单类型在开票过程中都需要使用不同的方法。 Billtype 表可能只有少数条目，并且不应增长得很大。

使用继承来子类化抽象 Billtype 实体是否有意义，该实体还为发票代码所需的不同方法定义了一个接口(interface)？像这样的事情:

@Entity
@DiscriminatorColumn("description")
public abstract class BillType {
   // Getters, setters
   // Abstract methods that could be used elsewhere - ex:
   // BigDecimal calculateInvVal(...)
}


@Entity
@DiscriminatorValue("by case")
public class CaseBillType extends BillType {
   // Implementation of calculateInvVal - now when invoicing code needs this method, 
   // the right one is always associated with the current product!
}

这提供了一种将行为与数据库中表示配置数据的字段关联起来的便捷方法，但将业务代码与实体混合在一起(在大多数情况下，这非常非常顽皮)。可能有一种设计模式可以解决这个问题，但我真的很想避免编写大量“如果账单类型是这样，则获取这个子类，如果账单类型是这样，等等” “代码。

我从答案中寻找的是对该技术潜在缺点的解释，我可能看不到这可以证明寻找此问题的另一种解决方案是合理的。

Answer 1

如果可以在运行时添加、删除和修改帐单类型，而无需重建和重新部署新版本的应用程序，则将产品与 BillType 实体链接起来非常有用。您的示例并非如此。

因此，如果您拥有一组静态的账单类型，每个类型都定义由 BillType 子类封装的静态行为，那么您可以简单地使用 BillType 枚举来代替。该枚举的每个实例定义其自己的行为。为此，您不需要实体层次结构和附加表。

计算 Product 实体中 InVal 的代码完全相同:

BigDecimal computeInVal() {
    billType.calculateInVal(this);
}

获取所有帐单类型的代码是

return BillType.values();

而不是使用以下代码将账单类型与产品关联:

product.setBillType(em.find(BillType.class, ID_OF_CASE_BILL_TYPE));

你只会有

product.setBillType(BillType.BY_CASE);