ASP.NET MVC - что эквивалентно ViewState - PullRequest
2 голосов
/ 28 февраля 2012

У меня есть существующий веб-сайт веб-форм, который работает на веб-ферме (несколько веб-серверов, каждый запрос не является липким).

Одной из задач является получение большого количества данных от стороннего веб-сервиса. Это дорогостоящий процесс (с точки зрения времени, необходимого для ответа). Оптимальным решением было изначально собрать все данные и вставить их в ViewState страницы (в виде списка ). Затем у нас есть сетка, которая позволяет пролистывать этот список продуктов. Для каждого запроса на следующую страницу мы не нужно повторно посещать медленный веб-сервис, потому что мы уже кэшировали данные в ViewState.

Итак, как бы я это сделал, используя MVC? Если бы я использовал классический ASP, я бы сериализировал список и держал его в скрытом поле в форме.

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

Если я хочу держать его в скрытом поле, то имеет ли смысл сначала сжимать данные (zip), чтобы уменьшить размер страницы? Опять же, что такое «лучшая практика» здесь?

Большое спасибо за любые / все советы

Griff

PS - я знаю, что есть похожие посты (например, ASP.NET MVC и ViewState ), но они не совсем предоставляют детали, которые мне требуются.

Ответы [ 2 ]

4 голосов
/ 28 февраля 2012

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

Это можно разделить кеш между многими веб-серверами. Поведение по умолчанию заключается в том, чтобы хранить его в InProcess, но это ни в коем случае не является фиксированным и может быть сконфигурировано для хранения его в удаленном кеше InProc, базе данных или любом другом методе полупостоянного хранения. Azure Запоминается кеширование AppFabric.

Во-вторых, как вы упомянули, нужно сбросить все данные в скрытом поле, но мне не нравится эта идея по ряду причин

  • Раздувание страницы - вы отправляете эти данные каждый раз, когда страница изменяется
  • Потерянные данные - вы должны отправить форму для каждой навигации, забыв сделать это, значит потерять ваши данные

К имени 2.

3 голосов
/ 28 февраля 2012

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

  • Изменчиво и дорого .Я бы пошел по пути кеширования данных в распределенном кеше, таком как Appfabric Velocity или Memcached.
  • Энергонезависимый и дорогой .Кэшируйте его копию в памяти на каждом узле сервера.
  • Дешевый .Хит звонить каждый раз, когда вам это нужно.Не беспокойтесь о кэшировании.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...