The paging problem is a very common problem that almost all developers will encounter. I will not discuss how to do paging specifically here, but will explain the principle of paging in Web mode. The first is to query to obtain a result set (shown as the results obtained from querying the database). If there are many results, we generally will not display all the data at once, then we will use paging to display certain data (such as 20 items). Because of the stateless nature of HTTP, each submission is treated as a new request. Even if the page is changed, the last result has no impact on the next one.
Here are three ways to implement paging. I don’t know if there are any others!
1. Get all the data of the query results each time, and then display the specified records according to the page number.
2. Get only one page of data based on the page, and then display this page. Here you need to construct a sql statement.
3. Taking a certain number of pages of data is a compromise between the previous two.
What should also be noted here is whether the data is placed in the request or the session, which will be discussed one by one here.
1. Generally it will not be placed in the session because it will occupy a lot of memory, so it should be placed in the request.
Advantages: The implementation is relatively simple and the query speed is relatively fast.
Disadvantages: It takes up more memory and transmits a lot of data over the network.
This method is more suitable for queries with relatively small amounts of data. Some people here put the data in the session so that there is no need to re-query when changing pages. However, this is extremely bad and is strongly recommended not to be used in this way.
2. It will definitely not be placed in the session, because it makes no sense to put it in the session.
Advantages: takes up less memory.
Disadvantages: It is more troublesome. You must first obtain the total number of query results, because you need to know how many records there are to know how many pages there are. In addition, it is necessary to construct a paging query statement, which is different for different databases.
3. This situation must be placed in the session, otherwise why would I fetch several pages? This implementation is to reduce the number of database queries. For example, if I save records 1 to 10, then if I change the page, Between 1 and 10 can be obtained directly from the session. If I change to page 11, I can reset the cache to 11
20 pages of data (or 5 to 15 pages of data), in this case, only one database query operation is required for 10 changes.
Advantages: It takes up relatively little memory and improves the average query speed.
Disadvantages: It is more complex to implement, dirty data may exist, and you need to define a cache collection yourself. If the amount of data queried is relatively large, you can consider using this method.
The following design only obtains one page of data each time, and the total number of queries must be reset each time. How to implement it yourself? This is a relatively common paging implementation.
Design an interface here:
package treeroot.util;import java.util.List;/*** This interface is used to implement the paging function. Note that no modification function is provided here. * @author treerot* @version 1.0* @since 2004-9-30*/public interface Pageable{ /** * Get data results* @return */ public List getResult(); /** * Get the total number of queries* @return */ public int getCount(); /** * Get the number of records per page* @return */ public int getPageSize(); /** * Get the current page number* @return */ public int getCurrentPage(); /** * Get the total number of pages* @return */ public int getPages(); /** * The default number of records displayed on each page*/ public final static int DEFAULT_PAGESIZE=20;} This interface is very simple. It includes a result list and some necessary information for paging. Note a few points here:
1. The implementation of this interface represents a certain page of data in a certain query, which has nothing to do with the last query.
2. The implementation of this interface should be read-only, which means it cannot be modified.
3. The getPages() method is redundant, but this method is still provided here.
An abstract implementation is given below:
package treeroot.util;import java.util.List;/*** @author treerot* @version 1.0* @since 2004-9-30*/public abstract class AbstractPage implements Pageable{ private int currentPage; private int pageSize; private int pages; protected int count; protected List result; /** * Specify the current page* @param currentPage * @throws PageException */ public AbstractPage(int currentPage){ this(currentPage,Pageable.DEFAULT_PAGESIZE); } /** * Specify the current page and page size* @param currentPage * @param pageSize * @throws PageException */ public AbstractPage(int currentPage,int pageSize) { this.currentPage=currentPage; this.pageSize=pageSize; } protected void checkPage(int currentPage) throws PageException{ if((currentPage<1)||(currentPage>this.getPages())) throw new PageException("Page out of range: the total number of pages is "+this.getPages()+", the current page is "+currentPage); } /** * This method is overridden by the subclass for initialization, that is, to calculate the count value and result, and is called in the constructor of the subclass. */ abstract protected void init() throws 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 pages; }}This abstract class implements all methods in the interface, but defines an abstract method init(), which must be implemented in subclasses. The above interface and abstract class look relatively simple. You may feel that they have done nothing. Indeed, they have done nothing in terms of implementation, but they can bring great help to development. We can inherit this abstract class according to our own needs, and the data can be obtained in various ways, such as directly through a List, or through JDBC, Hibernate, etc., but we all need to encapsulate the results into a List, through Hibernate It seems particularly convenient.
PageException is a custom exception
package treeroot.util /*** @author treeroot* @version 1.0* @since 2004-9-30*/public class PageException extends Exception{ public PageException(){ super(); } public PageException(String message){ super( message); }}