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