Я создаю AJAX-приложение, и у меня есть выбор, как структурировать функциональность подкачки данных. По сути, пользователь собирается работать с 1000-2000 записей, но только 20 записей одновременно загружаются из БД, отправляются клиенту и затем кэшируются в локальном хранилище сеансов. Эти записи являются строками json, которые содержат свойство объекта (в основном запись клиента).
Вот два варианта, давайте предположим, что мы работаем с 1500 записями и каждая страница имеет длину 20 записей. Дилемма - где хранить 1500 идентификаторов записей.
Вариант 1:
Идентификаторы 1500 записей хранятся в виде списка int в сеансе сервера , сериализуются и десериализуются для каждого запроса. Клиент не знает идентификаторов записей каждой страницы и просто запрашивает номер страницы. На сервере, когда пользователь запрашивает страницу X, мы смотрим на список int и определяем идентификаторы записей для страницы X, загружаем эти записи и отправляем клиенту строки json с этими идентификаторами. Недостатком здесь является то, что в сеансе сервера у нас есть список из 1500 int. Плюс в том, что когда мы запрашиваем страницу, мы отправляем серверу только int.
Вариант 2:
Идентификаторы 1500 записей отправляются клиенту, когда пользователь входит в систему, а затем этот список сохраняется в локальном сеансе хранения . Когда пользователь запрашивает страницу X, функция javascript определяет, какие идентификаторы записи находятся на странице X, и отправляет серверу сериализованный список json размером 20 дюймов. Затем сервер возвращает записи с этими идентификаторами. Положительным моментом является то, что сеанс на стороне сервера намного легче, и это должно повысить производительность (не нужно читать / записывать / сериализовать этот список при каждом запросе) и, вероятно, быть более масштабируемым. Недостатком является то, что каждый раз, когда мы запрашиваем страницу, мы отправляем серверу список из 20 дюймов.
Я полагаюсь на вариант 2: это лучший способ сделать это?
Примечание 1) что я требую от пользователей поддержки локального хранилища HTML5 и 2) реализация на стороне сервера будет Azure и WCF.