实体中可以有非持久变量吗？
当使用 ORM 时，拥有一个具有一些非持久属性的模型类（这些属性仅用于计算，然后可以安全地删除）是否会破坏某种良好实践？
假设我们有一个产品。该产品有可能的选项列表。期权可能会对产品的价格产生影响。我们还有一套规则，规定当选择一个选项时，另一个选项的价格就会发生变化。
当我们将产品添加到订单以及选择的期权时，我们首先需要根据影响每个选定期权的规则重新计算所有期权的价格。然后我们可以计算产品及其所有选定选项的最终价格。
在此示例中，选项可以具有计算价格属性，该属性仅在所选选项的上下文中有意义，并且可以在将产品添加到订单后安全地删除。
有没有更正确的方式来思考这个问题，或者可以吗？
When using an ORM, is it breaking some kind of good practice to have a model class with a few non-persistent properties, which are only used for calculations, and then can be safely dropped?
Let's say we have a Product. This Product has list of possible Options. An Option may have a price impact on the Product. We also have a set of Rules, which say that when one Option is selected, then the price of another Option changes.
When we add a Product to an Order, along with a selection of Options, we first need to recalculate the price of all the Options based on the rules affecting each selected Option. Then we can calculate the final price of the Product with all its selected Options.
In this example, the Option could have a calculatedPrice property, which would only have meaning within the context of the selected Options, and could be safely dropped after the Product has been added to the Order.
Is there a more correct way to think about this problem, or is that ok?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，拥有
@Transient属性是完全可以的。有些人可能会认为这是错误的，并坚持拥有一个与实体几乎相同的单独类，但具有附加字段，但这是不必要的代码重复。你的做法就是我会做的。
Yes, it is perfectly fine to have
@Transientproperties.Some people may consider it wrong and insist on having a separate class that is almost the same as the entity, but having the additional fields, but that is unnecessary code duplication. Your approach is what I'd do.
另一种方法是在我使用的一个大型且可怕的电子商务系统中使用的，它是具有包含计算信息的瞬态对象的并行结构。因此，与订单并行的是，还有一个订单价格。对于订单中的每个商品，都有一个商品价格。如果一个 Item 有一组 Options，那么 ItemPrice 将有一组 OptionPrice。订单的 ShippingOption 还具有 ShippingPrice 等。然后，定价由价格计算器的另一个并行结构处理 - 您向 OrderPriceCalculator 发出订单，它会返回 OrderPrice。这样做时，它将把每个 Item 发送到 ItemPriceCalculator，后者又将每个 Option 发送到 OptionPriceCalculator，依此类推。
价格对象可以引用订单对象，但反之则不行。我们的系统实际上确实保留了价格，但与订单分开。
这样做的好处是，它分离了描述订单内容、描述订单价格和计算订单价格的关注点。
缺点是你有大量的类，而你需要的信息不可避免地不在你必须掌握的对象中。
缺点可能大于优点。
The other approach, which is used in a large and ghastly e-commerce system i work with, is to have a parallel structure of transient objects containing the computed information. So, in parallel to the Order, there is an OrderPrice. For each Item in the order, there is an ItemPrice. If an Item has a set of Options, then the ItemPrice will have a set of OptionPrices. The Order's ShippingOption also has a ShippingPrice, and so on. Pricing is then handled by another parallel structure of price calculators - you give an Order to an OrderPriceCalculator, and it gives you back an OrderPrice. In doing so, it will send each Item to the ItemPriceCalculator, which will send each Option to the OptionPriceCalculator, and so on.
The price objects can refer to the order objects, but not vice versa. Our system does actually persist the prices, but separately from the orders.
The advantage of this is that it separates the concerns of describing the contents of an order, describing the price of an order, and calculating the price of an order.
The disadvantage is that you have a huge number of classes, and the information you need is, inevitably, never in the objects you have to hand.
The disadvantage probably outweighs the advantage.