Способы хранения объекта в нескольких постбэках

Question

Ради аргумента предположим, что у меня есть веб-форма, которая позволяет пользователю редактировать детали заказа.Пользователь может выполнять следующие функции:

• Изменить детали доставки / оплаты (все простые тексты / выпадающие списки)
• Добавить / удалить / редактировать товары в заказе - это делается с помощью сетки
• Добавить / удалить вложения

Продукты и вложения хранятся в отдельных таблицах БД с внешним ключом для заказа.

Entity Framework (4.0) используется в качестве ORM.

Я хочу разрешить пользователям вносить любые изменения в порядок, которые они хотят, и только когда они нажимают «Сохранить», я хочу зафиксировать изменения в базе данных.Это не проблема с текстовыми полями / флажками и т. Д., Так как я могу просто положиться на ViewState, чтобы получить необходимую информацию.Однако сетка представляет для меня гораздо большую проблему, так как я не могу найти хороший и простой способ сохранить изменения, сделанные пользователем, без фиксации изменений в базе данных.Сохранение дерева объектов Order в Session / ViewState - это не совсем та опция, с которой я бы хотел пойти, поскольку объекты могут стать очень большими.

Так что вопрос в том, как мне сохранить изменения, внесенные пользователем.сделано до готовности к «Сохранить».

Быстрое примечание - я искал SO, чтобы попытаться найти решение, однако все, что я нашел, было предложениями использовать Session и / или ViewState - оба из которых я хотел быскорее не использовать из-за потенциального размера деревьев моих объектов

Answer 1

2 подхода - создать сложное AJAX-приложение, которое хранит все на клиенте и передает только весь пакет изменений на сервер. Я сделал это один раз несколько лет назад с умеренным успехом. Заявление не то, что я хотел бы сохранить, хотя. Вам сложно синхронизировать код клиента с кодом сервера, и передача, добавление / удаление / изменение полей - кошмар.

2-й подход - хранить изменения в базе данных во временной таблице или в режиме ожидания. Преимущество в том, что ваш код более удобен в обслуживании. Недостаток в том, что у вас должен быть способ убрать оставленные изменения из-за тайм-аута сеанса, сбоя питания, других сбоев. Я бы взял этот подход для любой новой разработки. Вы можете иметь отдельные таблицы для «ожидающих» и «зафиксированных» изменений, которые открывают совершенно новый уровень возможностей, которые вы можете добавить. Что, если? Что изменилось? и т.д.

Answer 2

Один сервер: сериализация в файловую систему. Это также позволяет вам возобновить работу пользователя позже. Несколько серверов: сериализуйте его, но сохраните сериализованное значение в БД.

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

В качестве альтернативы, если набор данных v. Большой, а количество изменений обычно невелико, вы можете вместо этого сохранить историю изменений, выполненных пользователем. При этом вы также можете показать историю изменений + поддержка отмены.

Answer 3

Вы должны иметь возможность создать временный файл и сериализовать объект к нему, а затем сохранить только имя временного файла в viewstate. Как только они успешно сохранят запись обратно в базу данных, вы можете удалить временный файл.