当使用ORM时,是否打破某种良好做法以使模型类具有一些非持久性属性,这些属性仅用于计算,然后可以安全地删除?
假设我们有一个产品。本产品包含可能的选项列表。期权可能对产品产生价格影响。我们还有一套规则,即当选择一个选项时,另一个选项的价格会发生变化。
当我们向订单添加产品以及选择的选项时,我们首先需要根据影响每个选定选项的规则重新计算所有选项的价格。然后,我们可以使用所有选定的选项计算产品的最终价格。
在此示例中,Option可以具有computedPrice属性,该属性仅在所选选项的上下文中具有意义,并且可以在将产品添加到订单后安全地删除。
有没有更正确的方法来思考这个问题,还是没关系?
答案 0 :(得分:1)
是的,拥有@Transient
属性非常好。
有些人可能会认为这是错误的,并且坚持要求一个与实体几乎相同的单独类,但要有其他字段,但这是不必要的代码重复。你的方法就是我要做的。
答案 1 :(得分:1)
在我使用的大型可怕的电子商务系统中使用的另一种方法是具有包含计算信息的瞬态对象的并行结构。因此,与订单并行,有一个OrderPrice。对于订单中的每个商品,都有一个ItemPrice。如果一个Item有一组Options,那么ItemPrice将有一组OptionPrices。 Order的ShippingOption也有ShippingPrice,依此类推。然后定价由价格计算器的另一个并行结构处理 - 您将订单交给OrderPriceCalculator,它会返回OrderPrice。在这样做时,它会将每个Item发送到ItemPriceCalculator,它将每个Option发送到OptionPriceCalculator,依此类推。
价格对象可以引用订单对象,但反之亦然。我们的系统实际上确实持有价格,但与订单分开。
这样做的好处在于它区分了描述订单内容,描述订单价格和计算订单价格的顾虑。
缺点是你拥有大量的课程,而且你所需要的信息不可避免地存在于你必须掌握的物品中。
缺点可能超过了优势。