В настоящее время я работаю над добавлением некоторого управления заказами в приложении электронной коммерции Rails.
Требуется, чтобы вы вводили сеанс редактирования для заказа, а затем делали предложение изменения в элементах заказа (это могут быть такие вещи, как отмена элемента, добавление элемента и т. д. c), после чего эти изменения отражаются в пользовательском интерфейсе, например, обновление итогов заказа, изменение сальдо. Но ни одно из этих действий не должно сохраняться до тех пор, пока пользователь не нажмет save.
Я ищу несколько советов по поводу наиболее правильного Rails способа обработки такого рода паттернов, трудного для меня В связи с тем, что используемые модели являются довольно сложными и вложенными, действия, связанные, например, с отменой элемента, на первый взгляд являются простым вызовом метода, но для полного контрольного журнала в фоновом режиме выполняется больше всего.
Подходы До сих пор я размышлял:
- Создание этой простой задачи презентации и просто корректировка чисел, отображаемых на экране, в зависимости от того, что было выбрано (моя главная проблема в том, что это усложняется, например, добавляются скидки, мультивалютность et c, где уже достаточно много логики c, построенной вокруг ордеров для вычисления этих значений, и я не думаю, что это очень тривиальная проблема, а затем просто изменить их для представления без прохождения полного процесса и поэтому может привести к расхождениям)
- Использование s Один из типов черновой модели с помощью has_draft или чертежника драгоценных камней, опять же вложенная природа нашего моделирования и сложности в управлении состоянием, что беспокоит меня с этим подходом
- Обеспечение что любой процесс, который мы используем для этих компенсаций, работает транзакционно. Отделение пользовательского интерфейса от процесса до момента, когда наш пользовательский интерфейс почти создает набор инструкций , который используется в нашем бэкэнде, чтобы применить изменения и убедиться, что эти изменения могут быть выполнены как часть транзакции, а затем в случае необходимости прервано, это позволит нам поддерживать нашу сложную логику c и вычислять все точно так же, как это было бы, когда пользователь хочет сохранить изменения, но чувствует, что мы злоупотребляем Active Запишите транзакцию , если мы намеренно откатились назад, поскольку нам нужно было только предварительно просмотреть изменения, а также не уверены, насколько это опасно.
Любое понимание того, где подобная проблема была решена ранее , если будет некий шаблон, который я пропускаю и который мог бы помочь с этой функцией, был бы очень признателен, извиняюсь, если вопрос кажется запутанным, довольно трудно express узнать все детали функции и трудности вокруг нее, пытаясь держать кратко.
РЕДАКТИРОВАТЬ Перечитав мой вопрос, я думаю, что я достаточно сложным образом изложил, я пытался дать полный объем проблемы, то есть, какой результат мы хотим, но я думаю, пытаясь обеспечить альтернативные подходы и почему они не работают, я сделал более сложным. Я полагаю, что что-то в соответствии с подходом 3 - это то, что нам нужно с маршрутом предварительного просмотра изменений. Тогда постановке задачи присваивается набор методов, которые необходимо вызвать, как мы можем предварительно просмотреть результаты этих действий, не сохраняя ничего после этого. Описанный выше подход с использованием транзакции может выглядеть примерно так:
new_total = nil
ActiveRecord::Base.transaction do
@order.amend(instruction_set)
new_total = @order.total
raise ActiveRecord::Rollback
end
render json: new_total
Я просто обеспокоен безопасностью этого.