Проблема с пейджингом — очень распространенная проблема, с которой сталкиваются практически все разработчики. Я не буду обсуждать здесь конкретно, как это сделать, но объясню принцип пейджинга в веб-режиме. Первый — выполнить запрос для получения набора результатов (показанного как результаты, полученные в результате запроса к базе данных). Если результатов много, мы обычно не будем отображать все данные сразу, тогда мы будем использовать разбиение по страницам для отображения определенных данных (например). как 20 шт.). Из-за отсутствия сохранения состояния HTTP каждая отправка рассматривается как новый запрос. Даже если страница изменяется, последний результат не влияет на следующий.
Вот три способа реализации пейджинга. Не знаю, есть ли другие!
1. Каждый раз получайте все данные результатов запроса, а затем отображайте указанные записи в соответствии с номером страницы.
2. Получите только одну страницу данных на основе страницы, а затем отобразите эту страницу. Здесь вам нужно построить оператор sql.
3. Взятие определенного количества страниц данных — это компромисс между двумя предыдущими.
Здесь также следует отметить, помещаются ли данные в запрос или сеанс, которые будут обсуждаться здесь по отдельности.
1. Обычно он не будет помещен в сессию, поскольку будет занимать много памяти, поэтому его следует поместить в запрос.
Преимущества: реализация относительно проста, а скорость запросов относительно высокая.
Недостатки: занимает больше памяти и передает по сети много данных.
Этот метод больше подходит для запросов с относительно небольшими объемами данных. Некоторые здесь помещают данные в сессию, чтобы не было необходимости делать повторный запрос при смене страниц. Однако это крайне плохо и использовать таким образом категорически не рекомендуется.
2. В сессию он точно не поместится, ибо нет смысла ставить его в сессию.
Достоинства: занимает меньше памяти.
Недостатки: Это более хлопотно. Сначала необходимо получить общее количество результатов запроса, поскольку вам нужно знать, сколько записей, чтобы узнать, сколько страниц. Кроме того, необходимо построить оператор страничного запроса, который различен для разных баз данных.
3. Эту ситуацию необходимо поместить в сессию, иначе зачем мне выбирать несколько страниц. Эта реализация предназначена для уменьшения количества запросов к базе данных. Например, если я сохраняю записи с 1 по 10, то если я изменю страницу, между 1? и 10 можно получить непосредственно из сеанса. Если я перейду на страницу 11, я смогу сбросить кеш до 11.
20 страниц данных (или от 5 до 15 страниц данных), в этом случае для 10 изменений требуется только одна операция запроса к базе данных.
Преимущества: занимает относительно мало памяти и повышает среднюю скорость запросов.
Недостатки: его сложнее реализовать, могут существовать «грязные» данные, и вам придется самостоятельно определять коллекцию кэша. Если объем запрашиваемых данных относительно велик, вы можете рассмотреть возможность использования этого метода.
Следующий проект каждый раз получает только одну страницу данных, и общее количество запросов необходимо каждый раз сбрасывать. Как реализовать это самостоятельно. Это относительно распространенная реализация разбиения на страницы.
Проектируем интерфейс здесь:
packagetreeroot.util;import java.util.List;/*** Этот интерфейс используется для реализации функции разбиения по страницам. Обратите внимание, что здесь не предусмотрена никакая функция модификации. * @author Treerot* @version 1.0* @since 30-9-2004*/public Interface Pageable{ /** * Получить результаты данных* @return */ public List getResult(); /** * Получить общее количество запросов * @return */ public int getCount(); /** * Получить количество записей на странице* @return */ public int getPageSize(); /** * Получить номер текущей страницы* @return */ public int getCurrentPage(); /** * Получить общее количество страниц* @return */ public int getPages() /** * Количество записей по умолчанию, отображаемых на каждой странице*/ public Final static int DEFAULT_PAGESIZE=20;} Этот интерфейс очень прост. Он включает в себя список результатов и некоторую необходимую информацию для разбиения по страницам. Обратите внимание на несколько моментов:
1. Реализация этого интерфейса представляет собой определенную страницу данных в определенном запросе, не имеющем никакого отношения к последнему запросу.
2. Реализация этого интерфейса должна быть доступна только для чтения, то есть ее нельзя модифицировать.
3. Метод getPages() является избыточным, но этот метод здесь все же присутствует.
Абстрактная реализация приведена ниже:
package Treeroot.util;import java.util.List;/*** @author Treerot* @version 1.0* @since 2004-9-30*/public абстрактный класс AbstractPage реализует Pageable { Private int currentPage; Private Int PageSize; количество страниц; защищенный результат списка; /** * Укажите текущую страницу* @param currentPage * @throws PageException */ public AbstractPage(int currentPage){ this(currentPage,Pageable.DEFAULT_PAGESIZE); } /** * Укажите текущую страницу и размер страницы* @param currentPage * @param pageSize * @throws PageException */ public AbstractPage(int currentPage,int pageSize) { this.currentPage=currentPage; ; this.pageSize=pageSize; } protected void checkPage(int currentPage) выдает PageException {; if((currentPage<1)||(currentPage>this.getPages())) throw new PageException("Страница вне диапазона: общее количество страниц равно "+this.getPages()+", текущая страница равна " +currentPage); } /** * Этот метод переопределяется подклассом для инициализации, то есть для вычисления значения счетчика и результата, и вызывается в конструкторе подкласса. */ абстрактная защищенная пустота init() бросает PageException; public List getResult() { return result; } public int getCount() { return count; } public int getPageSize() { return pageSize; } public int getCurrentPage() { return currentPage; } public int getPages() { if(pages==0) this.pages=(count+pageSize-1)/pageSize return; страницы }}Этот абстрактный класс реализует все методы интерфейса, но определяет абстрактный метод init(), который должен быть реализован в подклассах. Вышеупомянутый интерфейс и абстрактный класс выглядят относительно просто. Вам может показаться, что они ничего не сделали с точки зрения реализации, но они могут оказать большую помощь в разработке. Мы можем наследовать этот абстрактный класс в соответствии с нашими собственными потребностями, а данные можно получать различными способами, например, напрямую через List или через JDBC, Hibernate и т. д., но нам всем необходимо инкапсулировать результаты в List, через Hibernate Кажется особенно удобным.
PageException — это специальное исключение.
package Treeroot.util /*** @author Treeroot* @version 1.0* @since 30-9-2004*/public класс PageException расширяет Exception { public PageException() { super(); } public PageException(String message) { super( сообщение); }}