Сохранение сложных данных между постбеками в ASP.NET MVC

Question

Я разрабатываю приложение ASP.NET MVC 2, которое подключается к некоторым службам для поиска и обновления данных. Услуги требуют, чтобы я предоставлял исходную сущность вместе с обновленной сущностью при обновлении данных. Это сделано для отслеживания изменений и оптимистичного параллелизма. Услуги не могут быть изменены.

Моя проблема в том, что мне нужно каким-то образом сохранять исходную сущность между постбеками. В WebForms я бы использовал ViewState, но из того, что я прочитал, это не относится к MVC. Исходные значения не должны быть доказательством несанкционированного доступа, так как сервисы считают их ненадежными. Объекты будут (максимум) 1 КБ, и это приложение для внутренней сети.

Я выбрал следующие варианты:

1. Сессия - Исключено - Сохранение сущности в Сессии, но мне не нравится эта идея, так как нет планов делить сессию между
2. URL - исключено - данные слишком велики
3. HiddenField - Хранить сериализованный объект в скрытом поле, возможно, с шифрованием / кодированием
4. HiddenVersion - У сущностей есть поле версии (SQL), которое я могу поместить в скрытое поле. Затем при сохранении я получаю «оригинальную» сущность из сервисов и сравниваю версии, выполняя собственный оптимистический параллелизм.
5. Cookies - Как 3 или 4, но с использованием куки вместо скрытого поля

Я склоняюсь к варианту 4, хотя 3 будет проще. Это действительные варианты или я иду по неверному пути? Есть ли лучший способ сделать это?

Answer 1

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

В данный момент у нас (точно) тот же вопрос, и мы решили создать шаблон репозитория и связать его с файлом cookie.

Тогда, если это станет проблемой, мы можем просто вставить в диспетчер сеансов, менеджер БД или что-то еще, и наш код даже не должен знать из-за шаблона хранилища.

Мы возились с идеей скрытых полей, но это было слишком похоже на ViewState, и мы все ненавидели его в WebForms, поэтому идея была отвергнута. Но не только потому, что мы ненавидели состояние просмотра. Были проблемы, когда вы нажимали Ctrl F5. Содержимое будет очищено и что вы будете делать?

Таким образом, на данный момент это шаблон репозитория с файлом cookie, который может измениться, но реализация поддается изменению.

EDIT

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

Скрытые поля только увеличивали сложность, что по сути должно было быть очень простой проблемой.

По крайней мере, так думали по этому поводу.

Answer 2

Я не совсем уверен, почему Session - плохая идея, если клиенту не нужна эта резервная копия, поэтому хранение всего этого в памяти сервера звучит лучше всего; поскольку все остальные кандидаты отправляют с сервера на временное место в браузере клиентов, а затем возвращают его обратно, когда клиент выполняет какие-либо действия. Ситуация такова, что всякий раз, когда клиент отправляет ответный запрос, сервер распаковывает закодированные данные (либо в скрытое поле, cookie, URL и т. Д.) И, возможно, снова помещается на сервер! Это также трата пропускной способности IMO.

ОК, если клиенту нужна (для проверки) резервная копия, я бы рассмотрел скрытое поле (набор) или просто сериализовал данные в XML и поместил их где-нибудь в HTML.

EDIT

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

http://msdn.microsoft.com/en-us/library/ms178587%28VS.80%29.aspx

и просто сохранить состояние в базе данных.