Выбор стратегии разбиения на страницы книг без SQL

Question

У меня есть ArrayList из Book s, извлеченных из разных Merchant s и отсортированных на Java, в зависимости от предпочтений пользователя, в соответствии с ценой или отзывами клиентов:

List<Book> books = new ArrayList<Book>();

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

Моя идея заключалась в том, чтобы иметь, возможно, 25 списков книг на странице , а не использовать гиперссылки, которые отправляют данные формы в виде GET запроса параметров URL, гиперссылки с номерами страниц просто повторяют повторную отправку. форма с передачей запрошенного номера страницы в качестве дополнительного параметра формы POST.

<input type="hidden" id="pageNumber" value="0">
<a href="#" onClick="pageNumber=5; this.form.submit()">Page 5</a>

В этом случае страница 5 будет просто набором из 25 записей, начиная с 125-й (5 * 25) записи в ArrayList и заканчивая 149-й записью в ArrayList.

Есть ли лучший способ сделать это?

Answer 1

Выполните рефакторинг вашего приложения, чтобы, например, Hibernate извлекал данные из базовой базы данных.

Hibernate может выполнять всю сортировку и нумерацию страниц без необходимости постоянно хранить все это в памяти.

Answer 2

Сколько страниц результатов обычно просматривают пользователи? Насколько велики данные (всего или на запись)? Всегда ли этот большой список (статический) или создается по запросу?

Вместо того, чтобы возвращать страницу с 25 результатами, вы можете вывести (скажем) 200 в массиве JSON и использовать javascript для отображения n .. n + 24 результатов. Если у вас есть все результаты на странице, вы также можете выполнить сортировку там. Запросите 1x1.gif? User = u1 & action = что угодно, если вы хотите отслеживать пользователей (обновлять рекламу и т. Д.) При отображении другой страницы.

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

• меньше используемой полосы пропускания
• меньше запросов к серверу
• пользователь видит лучший ответ, потому что страницы обновляются быстрее (и сервер делает меньше запросов)

но вам нужно будет провести некоторый анализ, чтобы понять, поможет ли это вам. Например, если более половины людей всегда смотрят на вторую страницу результатов, вы также можете отправлять результаты с первой страницы 26-50.

С другой стороны, вы не захотите отправлять 500 результатов, если никто не заглядывает за страницу 3. Если вы не хотели раздувать цифры трафика. Или вы можете сделать что-то динамическое, например, отправлять меньшие страницы, когда доступно меньше пропускной способности. Боже, мы живем в первобытные времена.

Answer 3

IMO, запрос GET или POST не должен иметь большого значения, поэтому я бы сказал, делайте все, что плавает на вашей лодке (защита головы от RESTful опровержений).Большая вещь, о которой я все еще беспокоюсь, - хранить этот список в памяти.Извлечение его у отдельных продавцов кажется хорошим аргументом для того, чтобы не восстанавливать его каждый раз, когда запрашивается страница, но лично я бы все равно решил сохранить эти результаты в локальной базе данных, даже временно.Хранение такого большого количества данных в памяти на вашем сервере приложений будет иметь последствия, когда у вас много одновременно работающих пользователей.

Answer 4

У меня есть библиотека с открытым исходным кодом для решения проблемы разбиения на страницы в веб-приложении Java. Вот ссылка:

http://www.hdpagination.org

Возможно, вам стоит подумать.

Если у вас есть какие-либо вопросы, не стесняйтесь спрашивать.