0

當使用ORM時,是否打破了某種好的做法,讓模型類具有一些非持久屬性,這些屬性僅用於計算,然後可以安全地刪除?在一個實體中有一個非持久變量可以嗎?

比方說,我們有一個產品。本產品有可能的選項列表。選項可能會對產品產生價格影響。我們也有一套規則,它說當選擇一個期權時,另一個期權的價格會發生變化。

當我們將產品添加到訂單以及選項選項時,我們首先需要根據影響每個選定期權的規則重新計算所有期權的價格。然後我們可以計算產品的最終價格及其所有選項。

在此示例中,選項可能具有computedPrice屬性,該屬性僅在選定選項的上下文中有意義,並且可以在產品添加到訂單後安全地刪除。

有沒有更正確的方法來思考這個問題,或者是好的?

回答

1

是的,這是完全沒有@Transient屬性。

有些人可能會認爲它是錯誤的,並堅持要有一個與實體幾乎相同的獨立類,但有附加字段,但這是不必要的代碼重複。你的方法就是我要做的。

+0

我很高興甚至有一個名字!謝謝。 – Benjamin

1

另一種方法,用於我使用的大型可怕的電子商務系統,是具有包含計算信息的瞬態對象的並行結構。所以,與訂單平行,有一個OrderPrice。對於訂單中的每個項目,都有一個ItemPrice。如果一個項目有一組選項,那麼ItemPrice將有一組選項價值。訂單的ShippingOption也有一個ShippingPrice,等等。定價然後由另一個價格計算器的並行結構來處理 - 您向OrderPriceCalculator發出一個訂單,並且它返回一個OrderPrice。這樣做時,它會將每個項目發送到ItemPriceCalculator,這會將每個選項發送到OptionPriceCalculator,依此類推。

價格對象可以引用訂單對象,但反之亦然。我們的系統確實堅持價格,但與訂單分開。

這樣做的好處是,它可以分隔描述訂單內容,描述訂單價格和計算訂單價格的顧慮。

缺點是你有大量的類,並且你所需要的信息不可避免地永遠不會在你必須交給的對象中。

缺點可能大於優勢。

+0

謝謝你這個詳細的答案! – Benjamin

相關問題