在使用 ORM 时，让一个模型类具有一些非持久性属性，这些属性仅用于计算，然后可以安全地删除，这是否违反了某种良好做法？
假设我们有一个产品。该产品有可能的选项列表。期权可能对产品产生价格影响。我们还有一组规则，该规则说，选择一个选项时，另一个选项的价格更改。
当我们将产品与选项一起添加到订单时，我们首先需要根据影响每个选定选项的规则重新计算所有选项的价格。然后我们可以计算该产品及其所有选定选项的最终价格。
在本例中，Option 可能有一个 computedPrice 属性，该属性仅在所选 Options 的上下文中才有意义，并且可以在将 Product 添加到 Order 后安全地删除。
有没有更正确的方法来思考这个问题，或者这样可以吗？
【问题讨论】：
标签： orm persistence entity object-persistence object-relational-model
是的，拥有@Transient 属性非常好。
有些人可能会认为这是错误的，坚持有一个与实体几乎相同的单独类，但有额外的字段，但这是不必要的代码重复。你的方法是我会做的。
【讨论】：
在我使用的大型且可怕的电子商务系统中使用的另一种方法是具有包含计算信息的瞬态对象的并行结构。因此，与 Order 并行的是 OrderPrice。对于订单中的每个项目，都有一个 ItemPrice。如果一个项目有一组选项，那么项目价格将有一组选项价格。订单的 ShippingOption 也有一个 ShippingPrice，等等。然后定价由价格计算器的另一个并行结构处理 - 您向 OrderPriceCalculator 发出订单，它会返回一个 OrderPrice。这样做时，它会将每个 Item 发送到 ItemPriceCalculator，ItemPriceCalculator 会将每个 Option 发送到 OptionPriceCalculator，依此类推。
价格对象可以引用订单对象，反之则不行。我们的系统确实保留了价格，但与订单分开。
这样做的好处是，它将描述订单内容、描述订单价格和计算订单价格的关注点分开了。
缺点是你有大量的类，而你需要的信息不可避免地永远不会在你手头的对象中。
缺点可能大于优点。
【讨论】：