Стандартный способ сохранить данные между запросами в ASP.NET-MVC

Стандартный способ - передавать подобные вещи через параметры запроса URL. Вы можете изменить свою маршрутизацию, чтобы ожидать определенные переменные URL. Таким образом, страницы становятся более удобными для поисковых систем.

В ответ на ваше обновление, хорошим способом добиться этого для страниц было бы наличие ссылок на «Предыдущая» и «Следующая» "страницы результатов (или еще лучше, список всех страниц в списке), выводимые на страницу, с номерами страниц, которые вы затем скрываете с помощью JavaScript.

Таким образом, пользователи увидят ваше приятное AJAXy-поведение, а поисковые системы (и пользователи без JavaScript - мобильные устройства или пользователи, использующие старые программы чтения с экрана, например) по-прежнему смогут получить доступ ко всем вашим страницам - это поможет вам страницы для постепенного ухудшения качества или используйте «прогрессивное улучшение».

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

Сессия "слишком" проста. В среде разработчиков она работает отлично, практически независимо от того, что вы в нее вкладываете. В производстве масштабируемость и сохранение становятся проблемой. Внутрипроцессная сессия может неожиданно исчезнуть, если на вашем сайте произойдет ошибка, и требует привязки к серверу при балансировке нагрузки. Сессия вне процесса устраняет проблемы долговечности и аффинити, но все еще может быть "бутылочным горлышком" производительности, если в сессию помещается слишком много всего. ОЧЕНЬ распространенной проблемой является то, что каждая страница помещает 1-2 элемента в сессию, но никогда не вынимает их после завершения работы. И даже если страница удаляет данные сеанса, когда они больше не нужны, данные могут остаться бесхозными, если пользователь начинает процесс и не завершает его.

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

Это зависит от того, насколько постоянной вы хотите, чтобы информация была:

• Такие вещи, как номер страницы, действительно должны быть в URL-адресе (как указывали другие) - это помогает с закладки и т. д., но помните, что если вы добавите в список больше содержимого, то этот набор результатов с закладками не всегда будет тем, что хотел пользователь ...
• Если вы счастливы, что эти значения будут потеряны, когда время сеанса out (по умолчанию около 20 минут), затем поместите их в Session.
• Если вы считаете, что время ожидания сеансов истекает перед следующим запросом, или вы хотите сохранять его между посещениями, вам следует сохранять их либо в файлах cookie, либо в профиле (потенциально разрешая «анонимные» профили, которые работают с файлы cookie пользователей, чтобы они теряли их на разных машинах).

Лично я бы очень внимательно подумал о порядке сортировки и столбцах в URL-адресе, если вы это сделаете, вы действительно можете запутать поисковые системы:

1. Множество страниц с очень похожим содержанием (стр. 1, отсортировано по дате desc, страница 1, отсортированная по дате asc и т. д.) - поисковым системам не нравится дублированный контент, и вы, поскольку Google (например), не должны показывать только две страницы с вашего сайта в наборе результатов по умолчанию, вы хотите, чтобы они были действительный, а не дубликаты.
2. Поисковые системы будут тратить намного больше времени на сканирование вашего сайта и, возможно, откажутся от этого. Если на каждой странице они найдут ссылки на «Сортировать по этому столбцу», они будут пытаться следовать по ним, в результате чего на сервере будет больше работы, чем выше использование полосы пропускания и т. д.

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

Сессии самые простые.