Можно ли иметь непостоянную переменную в сущности?

Question

При использовании ORM нарушает ли какая-то хорошая практика иметь класс модели с несколькими непостоянными свойствами, которые используются только для вычислений и затем могут быть безопасно отброшены?

Давайтескажем, у нас есть продукт.Этот продукт имеет список возможных вариантов.Опцион может повлиять на цену Продукта.У нас также есть набор Правил, в которых говорится, что при выборе одного Опциона цена другого Опциона изменяется.

Когда мы добавляем Продукт в Заказ вместе с выбором Опций, нам сначала нужнопересчитать цену всех опционов на основе правил, влияющих на каждый выбранный опцион.Затем мы можем рассчитать окончательную цену Продукта со всеми его выбранными опциями.

В этом примере у опциона может быть свойствовычисленная цена, которая будет иметь значение только в контексте выбранных опций иблагополучно отброшен после того, как Продукт был добавлен в Заказ.

Есть ли более правильный способ думать об этой проблеме, или это нормально?

Answer 1

Другой подход, который используется в большой и ужасной системе электронной коммерции, с которой я работаю, - это иметь параллельную структуру временных объектов, содержащих вычисленную информацию. Таким образом, параллельно с Order, есть OrderPrice. Для каждого Предмета в заказе есть ItemPrice. Если у элемента есть набор параметров, то у ItemPrice будет набор параметров. Опция ShippingOption заказа также имеет ShippingPrice и так далее. Ценообразование затем обрабатывается другой параллельной структурой калькуляторов цен - вы передаете Order для OrderPriceCalculator, и он возвращает вам OrderPrice. При этом он отправит каждый Item в ItemPriceCalculator, который отправит каждый Option в OptionPriceCalculator и т. Д.

Объекты цены могут ссылаться на объекты заказа, но не наоборот. Наша система действительно сохраняет цены, но отдельно от заказов.

Преимущество этого состоит в том, что он разделяет задачи описания содержимого заказа, описания цены заказа и расчета цены заказа.

Недостаток в том, что у вас огромное количество классов, и необходимая информация неизбежно никогда не попадает в объекты, которые вы должны передать.

Недостаток, вероятно, перевешивает преимущество.

Answer 2

Да, прекрасно иметь свойства @Transient.

Некоторые люди могут счесть это неправильным и настаивать на том, чтобы иметь отдельный класс, который почти совпадает с сущностью, но имеет дополнительные поля, но это является ненужным дублированием кода. Твой подход - это то, что я бы сделал.