ORM を使用する場合、計算にのみ使用され、安全に削除できるいくつかの非永続的なプロパティを持つモデル クラスを持つことは、ある種の良い習慣を破っていますか?
Product があるとしましょう。この製品には、可能なオプションのリストがあります。オプションは、製品の価格に影響を与える場合があります。また、1 つのオプションが選択されると、別のオプションの価格が変わるという一連のルールもあります。
選択したオプションとともに製品を注文に追加する場合、まず、選択した各オプションに影響するルールに基づいて、すべてのオプションの価格を再計算する必要があります。次に、選択したすべてのオプションを使用して製品の最終価格を計算できます。
この例では、Option は、選択された Options のコンテキスト内でのみ意味を持ち、Product が Order に追加された後に安全に削除できる、calculatedPrice プロパティを持つことができます。
この問題について考えるより正しい方法はありますか、それとも問題ありませんか?
私が使用している大規模で恐ろしいeコマースシステムで使用されているもう1つのアプローチは、計算された情報を含む一時的なオブジェクトの並列構造を持つことです。したがって、Orderと並行して、OrderPriceがあります。注文のアイテムごとに、ItemPriceがあります。アイテムに一連のオプションがある場合、ItemPriceには一連のOptionPricesがあります。OrderのShippingOptionには、ShippingPriceなどもあります。次に、価格計算機の別の並列構造によって価格設定が処理されます。つまり、OrderPriceCalculatorに注文を渡すと、OrderPriceが返されます。そうすることで、各アイテムをItemPriceCalculatorに送信し、ItemPriceCalculatorは各オプションをOptionPriceCalculatorに送信します。
価格オブジェクトは注文オブジェクトを参照できますが、その逆はできません。私たちのシステムは実際には価格を維持しますが、注文とは別にします。
これの利点は、注文の内容の説明、注文の価格の説明、および注文の価格の計算の問題を分離することです。
不利な点は、クラスの数が非常に多く、必要な情報が必然的に、渡さなければならないオブジェクトに含まれないことです。
短所はおそらく長所を上回ります。
@Transientはい、プロパティを持つことはまったく問題ありません。
一部の人々はそれが間違っていると考え、エンティティとほとんど同じであるが追加のフィールドを持つ別のクラスを持つことを主張するかもしれませんが、それは不要なコードの重複です。あなたのアプローチは私がすることです。