java中如何实现分页显示

java中如何实现分页显示,第1张

一个简单的JAVA分页方法

定义两个Vector,一个为储存查询所有记录的totalV,另一个储存当前页的记录currentPageV;

总的记录数:int totalSize = totalVgetSize();

每页显示的记录数:int countPerPage;

总页数:int totalPageNum = totalSize/countPerPage;

//如果总的记录数和每页记录数的余数大于零,

//那么总的页数为他们的整除结果加一

if (totalSize%countPerPage > 0 ){

totalPageNum = totalSize/countPerPage + 1;

}

当前的页数:pageNum;

for (int j = 0;j<totalVsize();j++){

//分页,根据当前的页数和每页显示的记录数从totalV中取出记录

//往currentPageV中添加记录;

//如果当前记录在(当前页码-1)每页显示记录数(包括等于)

//和 当前页码每页显示记录数(不包括等于)之间的时候;

//就属于该页的数据

if ( (j >= (pageNum - 1) countPerPage) && (j < pageNum countPerPage)) {

currentPageVaddElement(totalVget(j));

}

//当currentPageV记录数等于每页显示记录数,

//停止往currentPageV中添加记录

if (currentPageVsize() == countPerPage) {

break;

}

}

那么,当前页中显示的记录,就是currentPageV中的记录。

第二个分页

在使用数据库的过程中,不可避免的需要使用到分页的功能,可是JDBC的规范对此却没有很好的解决。对于这个需求很多朋友都有自己的解决方案,比如使用Vector等集合类先保存取出的数据再分页。但这种方法的可用性很差,与JDBC本身的接口完全不同,对不同类型的字段的支持也不好。这里提供了一种与JDBC兼容性非常好的方案。

JDBC和分页

Sun的JDBC规范的制定,有时很让人哭笑不得,在JDBC10中,对于一个结果集(ResultSet)你甚至只能执行next() *** 作,而无法让其向后滚动,这就直接导致在只执行一次SQL查询的情况下无法获得结果集的大小。所以,如果你使用的是JDBC10的驱动,那么是几乎无法实现分页的。

好在Sun的JDBC2规范中很好的弥补了这一个不足,增加了结果集的前后滚动 *** 作,虽然仍然不能直接支持分页,但我们已经可以在这个基础上写出自己的可支持分页的ResultSet了。

和具体数据库相关的实现方法

有一些数据库,如Mysql, Oracle等有自己的分页方法,比如Mysql可以使用limit子句,Oracle可以使用ROWNUM来限制结果集的大小和起始位置。这里以Mysql为例,其典型代码如下:

// 计算总的记录条数

String SQL = "SELECT Count() AS total " + thisQueryPart;

rs = dbexecuteQuery(SQL);

if (rsnext())

Total = rsgetInt(1);

// 设置当前页数和总页数

TPages = (int)Mathceil((double)thisTotal/thisMaxLine);

CPages = (int)Mathfloor((double)Offset/thisMaxLine+1);

// 根据条件判断,取出所需记录

if (Total > 0) {

SQL = Query + " LIMIT " + Offset + " , " + MaxLine;

rs = dbexecuteQuery(SQL);

}

return rs;

}

毫无疑问,这段代码在数据库是Mysql时将会是漂亮的,但是作为一个通用的类(事实上我后面要提供的就是一个通用类库中的一部分),需要适应不同的数据库,而基于这个类(库)的应用,也可能使用不同的数据库,所以,我们将不使用这种方法。

另一种繁琐的实现方法

我看过一些人的做法(事实上包括我在内,一开始也是使用这种方法的),即不使用任何封装,在需要分页的地方,直接 *** 作ResultSet滚到相应的位置,再读取相应数量的记录。其典型代码如下:

<%

sqlStmt = sqlConcreateStatement(javasqlResultSetTYPE_SCROLL_INSENSITIVE,

javasqlResultSetCONCUR_READ_ONLY);

strSQL = "select name,age from test";

//执行SQL语句并获取结果集

sqlRst = sqlStmtexecuteQuery(strSQL);

//获取记录总数

sqlRstlast();

intRowCount = sqlRstgetRow();

//记算总页数

intPageCount = (intRowCount+intPageSize-1) / intPageSize;

//调整待显示的页码

if(intPage>intPageCount) intPage = intPageCount;

%>

<table border="1" cellspacing="0" cellpadding="0">

<tr>

<th>姓名</th>

<th>年龄</th>

</tr>

<%

if(intPageCount>0){

//将记录指针定位到待显示页的第一条记录上

sqlRstabsolute((intPage-1) intPageSize + 1);

//显示数据

i = 0;

while(i<intPageSize && !sqlRstisAfterLast()){

%>

<tr>

<td><%=sqlRstgetString(1)%></td>

<td><%=sqlRstgetString(2)%></td>

</tr>

<%

sqlRstnext();

i++;

}

}

%>

</table>

很显然,这种方法没有考虑到代码重用的问题,不仅代码数量巨大,而且在代码需要修改的情况下,将会无所适从。

使用Vector进行分页

还见过另一些实现分页的类,是先将所有记录都select出来,然后将ResultSet中的数据都get出来,存入Vector等集合类中,再根据所需分页的大小,页数,定位到相应的位置,读取数据。或者先使用前面提到的两种分页方法,取得所需的页面之后,再存入Vector中。

扔开代码的效率不说,单是从程序结构和使用的方便性上讲,就是很糟糕的。比如,这种做法支持的字段类型有限,int, double, String类型还比较好处理,如果碰到Blob, Text等类型,实现起来就很麻烦了。这是一种更不可取的方案。

一个新的Pageable接口及其实现

很显然,看过上面三种实现方法后,我们对新的分页机制有了一个目标,即:不与具体数据库相关;尽可能做到代码重用;尽可能与原JDBC接口的使用方法保持一致;尽可能高的效率。

首先,我们需要提供一个与javasqlResultSet向下兼容的接口,把它命名为Pageable,接口定义如下:

public interface Pageable extends javasqlResultSet{

/返回总页数

/

int getPageCount();

/返回当前页的记录条数

/

int getPageRowsCount();

/返回分页大小

/

int getPageSize();

/转到指定页

/

void gotoPage(int page) ;

/设置分页大小

/

void setPageSize(int pageSize);

/返回总记录行数

/

int getRowsCount();

/

转到当前页的第一条记录

@exception javasqlSQLException 异常说明。

/

void pageFirst() throws javasqlSQLException;

/

转到当前页的最后一条记录

@exception javasqlSQLException 异常说明。

/

void pageLast() throws javasqlSQLException;

/返回当前页号

/

int getCurPage();

}

这是一个对javasqlResultSet进行了扩展的接口,主要是增加了对分页的支持,如设置分页大小,跳转到某一页,返回总页数等等。

接着,我们需要实现这个接口,由于这个接口继承自ResultSet,并且它的大部分功能也都和ResultSet原有功能相同,所以这里使用了一个简单的Decorator模式。

PageableResultSet2的类声明和成员声明如下:

public class PageableResultSet2 implements Pageable {

protected javasqlResultSet rs=null;

protected int rowsCount;

protected int pageSize;

protected int curPage;

protected String command = "";

}

可以看到,在PageableResultSet2中,包含了一个ResultSet的实例(这个实例只是实现了ResultSet接口,事实上它是由各个数据库厂商分别实现的),并且把所有由ResultSet继承来的方法都直接转发给该实例来处理。

PageableResultSet2中继承自ResultSet的主要方法:

//……

public boolean next() throws SQLException {

return rsnext();

}

//……

public String getString(String columnName) throws SQLException {

try {

return rsgetString(columnName);

}

catch (SQLException e) {//这里是为了增加一些出错信息的内容便于调试

throw new SQLException (etoString()+" columnName="

+columnName+" SQL="+thisgetCommand());

}

}

//……

只有在Pageable接口中新增的方法才需要自己的写方法处理。

/方法注释可参考Pageablejava

/

public int getCurPage() {

return curPage;

}

public int getPageCount() {

if(rowsCount==0) return 0;

if(pageSize==0) return 1;

//calculate PageCount

double tmpD=(double)rowsCount/pageSize;

int tmpI=(int)tmpD;

if(tmpD>tmpI) tmpI++;

return tmpI;

}

public int getPageRowsCount() {

if(pageSize==0) return rowsCount;

if(getRowsCount()==0) return 0;

if(curPage!=getPageCount()) return pageSize;

return rowsCount-(getPageCount()-1)pageSize;

}

public int getPageSize() {

return pageSize;

}

public int getRowsCount() {

return rowsCount;

}

public void gotoPage(int page) {

if (rs == null)

return;

if (page < 1)

page = 1;

if (page > getPageCount())

page = getPageCount();

int row = (page - 1) pageSize + 1;

try {

rsabsolute(row);

curPage = page;

}

catch (javasqlSQLException e) {

}

}

public void pageFirst() throws javasqlSQLException {

int row=(curPage-1)pageSize+1;

rsabsolute(row);

}

public void pageLast() throws javasqlSQLException {

int row=(curPage-1)pageSize+getPageRowsCount();

rsabsolute(row);

}

public void setPageSize(int pageSize) {

if(pageSize>=0){

thispageSize=pageSize;

curPage=1;

}

}

//PageableResultSet2的构造方法:

public PageableResultSet2(javasqlResultSet rs) throws javasqlSQLException {

if(rs==null) throw new SQLException("given ResultSet is NULL","user");

rslast();

rowsCount=rsgetRow();

rsbeforeFirst();

thisrs=rs;

}

/如果要提高效率,可以利用select count() 语句取得所有记录数,注释掉

构造函数的rslast();rowsCount=rsgetRow();rsbeforeFirst();三句。

在调用构造函数后调用此方法获得所有的记录,参数是select count()后的结果集

/

public void setRowsCount(javasqlResultSet rs)throws javasqlSQLException {

if(rs==null) throw new SQLException("given ResultSet is NULL","user");

rowCount=rsgetInt(1);

}

这里只是简单的取得一个总记录数,并将记录游标移回初始位置(before first),同时将参数中的ResultSet赋给成员变量。

Pageable的使用方法

因为Pageable接口继承自ResultSet,所以在使用方法上与ResultSet一致,尤其是在不需要分页功能的时候,可以直接当成ResultSet使用。而在需要分页时,只需要简单的setPageSize, gotoPage,即可。

PreparedStatement pstmt=null;

Pageable rs=null;

……//构造SQL,并准备一个pstmt

rs=new PageableResultSet2(pstmtexecuteQuery());//构造一个Pageable

rssetPageSize(20);//每页20个记录

rsgotoPage(2);//跳转到第2页

for(int i=0; i<rsgetPageRowsCount(); i++){//循环处理

int id=rsgetInt(“ID”);

……//继续处理

rsnext();

}

总结

一个好的基础类应该是便于使用,并且具备足够的可移植性,同时要保证其功能的完善。在上面的实现中,我们从javasqlResultSet接口继承出Pageable,并实现了它。这就保证了在使用中与JDBC原有 *** 作的一致性,同时对原有功能没有缩减。

同时它也是易于使用的,因为封装了一切必要的 *** 作,所以在你的代码中唯一显得"难看"和"不舒服"的地方就是需要自己去构造一个PageableResultSet2。不过只要你愿意,这也是可以解决的。

当然它也有具有充分的可移植性,当你将数据库由Oracle变为Mysql或者SQLServer的时候,你仍然可以使用这些分页的代码。它在使用中(或者说在移植的过程中)唯一的限制就是你必须要使用一个支持JDBC2的驱动(现在明白为什么我把类命名为PageableResultSet2了吧。:P),不过,好在JDBC2已经成为标准了,绝大多数的数据库(如Oracle, Mysql, SQLServer)都有自己的或者第三方提供的JDBC2的驱动。

OK,这个分页的实现是否对你的编程有帮助呢?仔细看看,其实真正自己写的代码并不多的,大部分都只是简单的转发 *** 作。一个合适的模式应用可以帮你很大忙。

这里只是简单的取得一个总记录数,并将记录游标移回初始位置(before first),同时将参数中的ResultSet赋给成员变量。

常规的分页方式

API处理分页看似简单,实际上暗藏危机。最常见的分页方式,大概是下面这样的

/users/page=1&limit=5

//服务端返回

{

"code": 0,

"pagination": {

"page": 1,

"limit": 5,

"total": 10

}

"data": {}

}

最理想的情况下,客户端请求第一页的5条数据,服务端如常返回,比如下图:

拿Twitter的图用一下,假设我们的数据库有10条数据,按照5条一页,正好有2页。

在理想情况下,客户端拉取数据时不会出现任何异常。但,这仅仅是正常情况,如果此时刚好有2条新数据插入。

数据库记录变为13。原来第二页的数据是[5, 4, 3, 2, 1],现在变为[7, 6, 5, 4, 3],我们再一次拿到了第一页的数据。同理,如果用户在拉取数据时正好有数据被删除,一样会出现类似的问题。

根据item_id分页

要解决此类问题,就不能使用常规的分页方式。现在,我们换一个思路,客户端拉取数据时不再传page,改为item_id,我们就把它称为max_id

/users/max_id=5&limit=5

此时服务端就知道我们上次拉取到了item_id为5的数据,继续在它后面拉取5条, 如下图:

数据可以正常取回,不会再出现上一页中的[6,7]。好了,让我们再一次假设,此时又有8条数据插入了数据库。再一次获取数据

可以看出,再一次出现问题,我们又拿到了上一页的[10,9]。所以,我们得告诉服务端,上一次拿到哪一条数据了。所以继续增加一个since_id字段。

恩,再一次取出了正确的数据。可能你觉得一切都正常了,但还是隐藏了一个致命的缺陷。

上面的数据能正常获取,是因为数据都是一个有序的集合,如果数据无序,且从数据库取出时需要按照某个字段排序,那么一切再次打回原点:所有的分页都乱了。

如何设计分页API

可以看出,两种分页方式都存在问题。所以这两种需求都是必要的,我们需要根据不同的业务场景使用不同的分页方式。

为了不造成客户端的麻烦,我们对api的分页做了一些更改。

{

"code": 0,

"pagination": {

"page": 1,

"next": {

"sinceId": 11,

"maxId": 11

//page: 1

},

"limit": 5,

"total": 10

},

"data": {}

}

我们由服务端来决定如何分页,前端需要做的,只是把next字段直接拼接到url中,这样就可以应付各种分页情况。

传统分页的话,一般只考虑传页数和每页数据条数这两个参数给后端,为了方便后面描述,我们给这个传参方式起个名字叫 传统分页 。这种传参方式对于静态数据(数据不会变动)的分页是没问题的,因为每条数据的顺序、数据的总量,都是不变的。

如果出现数据顺序变动或者数据总量变动的分页需求时,单纯的传page和limit已经不能解决了。

不同的需求需要显示的列表也不一样。关于列表分页我认为主要关系到两个方面, 总量 (列表头插入了新数据) 和 排列顺序 传统分页 总量不变,排列顺序不变 的列表下是没有任何问题的,但只要这两个要素其中一个是变化的, 传统分页 方式就会出现BUG(具体案例后面会讲到)。关于上面提到两个要素对应的需求举例:

现在有一个积分排行榜

假定每页显示3条数据,在某一时刻拿第一页数据时,得到 A、B、C三条数据。就在此时,用户D突然增加了100积分,最新的排行榜情况变成了

传统分页 的情况下,获取第二页数据时,即从当前排行榜第四条数据开始获取,得到 C、E,用户看到的数据就变成 A、B、C、C、E。这里C出现了2次,而且D消失了。这就是传统分页用在 数据排列顺序会改变的列表 时会出现的问题,因为列表顺序改变导致出现重复数据和丢失数据。

这种 总量不变,排列顺序改变 的分页问题我能想到的暂时有两种方案解决:一次性取出、排行榜快照、通过变动记录表拿数据。

这里说的一次性取出是针对类似“top100”这种取有限条数的需求。在比较简单的列表数据结构下一次性取出100条数据对服务器性能来说问题不大,但是在复杂数据结构下(涉及关联多个表、数据格式化、数据处理等)一次性处理100或更多的数据肯定是糟糕的做法。

排行榜主要的分页问题是 影响排名的字段的值在不断变化导致列表顺序不断改变 ,我们现在可以一次性取出整个列表但是又担心复杂的数据结构导致服务器性能问题。那如果我们把整个功能拆分一下,用异步的思想来做这个功能设计如何呢。

我们分两个接口来做这个功能:获取排行榜列表和获取用户排行榜数据。

获取排行榜列表接口 一次性取整个排名列表的用户ID和排名相关的字段数据,这样就保证了整个列表的排序是不变的同时,又不增大服务器性能。

获取用户排行榜数据接口 负责取排行榜要显示的用户的其他数据,这个接口接受多个用户ID的作为参数。这个接口做了类似分页的功能,前端每次从排行榜中按分页的方式按顺序取部分用户ID,然后通过这个接口获取具体数据显示给用户。

下面以例子的方式来做具体说明:

这是一个 积分排行 top100

这里的排行条件是 积分 ,那我们的 获取排行榜列表接口 只需要取“用户ID”和“积分”即可,剩下的 “昵称”、“胜率”等数据通过 获取用户排行榜数据接口 获取。

前端先请求 列表接口,获取到一下数据:

然后根据这个列表数据,先取前10条的用户ID:5、12、60、2、77… 去请求 获取用户排行榜数据接口,把获得的用户数据填充到排行榜中。当用户下滑加载更多数据时再去列表取在11-20的用户ID重复上面的 *** 作。

如果是 top100 的需求,这个方案是比较 推荐 的,因为没有性能和储存空间上的额外消耗。

因为考虑到主要问题出在排列顺序是变化的,而且通过其他APP也有看到过按时刷新的排行榜,所以想到了用快照的方式来解决。

可以通过写一个定时脚本,每5分钟生成一次排行榜的快照信息并存下来。接口请求时直接从快照中取数据,这一定程度上解决了列表排序一直在变化问题。这里之所以说只解决了一定程度,是因为在每次刷新快照数据的时候,可能有用户刚好卡在这个时间点之间去请求(刷新快照前用户请求了第一页数据,刷新快照后用户请求第二页,这就出现 传统分页 同样的问题了)。

可以通过在快照中加上 版本号 来解决问题。例如在生成快照的时候以当前时间戳作为版本号跟快照数据一起保存,同时需要系统保存多份快照数据以便用户获取旧快照数据。请求接口时默认拿最新版本的快照,如果接口传入了版本号就拿对应版本号的快照数据。

每个完备的系统都会有数据变动的记录表,用于追踪数据变动和 *** 作明细。记录变记录着数据每次变动前后的变化和变动时间,这一特性为使得数据的每次变动都有迹可循,我们就是利用这一点来做排行榜的分页。

我们分页出问题的地方就是因为数据在不断变化导致排序不停改变。上面说到每次数据变动都会有记录,那我们只需要根据某一时刻之前用户的数据来做排名,是不是就解决数据不断变动这个问题。文字表达可能不太直观,看下面的数据演示应该能比较好理解。

假定用户 A、B、C 初始默认都是100积分

表: score_log

假定在03分的时候请求了数据,通过下面的SQL语句就可以拿到03分之前的数据排行。

得到第一页数据:

第二页数据:

关于这种方式的请求,前端需要记录发起第一次请求时的时间,以后每页的请求都带着这个时间。

评论列表一般按照倒叙排列,而且顺序不变。因为是倒叙排列,所以最新的用户评论会放在最顶部,这就会导致问题了。我们还是用实际例子来说。

假定每页拿3条数据,此时请求第一页,得到ID分别5、4、3的评论。在请求第二页之前,突然又来了一条留言,此时列表变成:

传统分页 方式,此时获取第二页会得到ID 3、2、1,这里ID 3 就重复取出来了。

这个问题的解决方案相比排行榜列表分页问题简单而且易懂。评论ID是一个自增的int字段,新的评论ID总是比旧评论ID要大,利用这一点我们可以很好的解决问题。

接口传参:

limit 就不用作解释,说一下lastid。当获取第一页数据时,因为没有上一页所以 lastid 传空或者不传,此时服务器取最新的数据即可。获取第二页数据时,lastid 传第一页最后一条数据的ID,此时服务器取 ID < lastid 的数据,这就保证最新的评论不会影响到当前用户的分页。

这里做一个扩展,我们有时候看到有的页面在刷新的时候,会提示有多少条新的未查看评论(即列表头新的数据),这个功能的实现原理跟我们上面分页的原理差不多。在获取第一页数据时,把第一页的第一条数据ID保存下来,后面请求每一页时都把第一条ID( firstid )带上,服务器每次查 ID > firstid 的数据条数,如果大于0即表示有新的评论。

首先说一下,下面提供的方法我自己也不满意(如果有什么想法欢迎大家留言交流)。参考了微博的评论排序也存在上面说到的分页bug,感觉要完美解决这个需求的分页问题花费的代价(实现时间、服务器性能、存储空间等)大于功能本身,所以建议读者选择比较折中的方式来处理(与产品或上级沟通实现的难度)。

这个需求相比评论列表,多了点赞的功能,列表按点赞数量倒叙排列。先说一下不严谨情况下这个分页的实现方式:

这种方式会有两个问题:

我们可以沿用上面讲到的两个需求的解决方案。在解决列表排序问题上,我们可以沿用排行榜的 通过变动记录表拿数据 方式,增加一个表去记录评论的点赞变动记录(用空间换效率)。

表结构:

分页用到的查询语句:

在hibernate的query接口查询出一个list后

list里有两个方法

listsetFirstResult(int a);

listsetMaxSize(int a);

第一个方法用来设置当前页要显示的第一条记录是从哪一个记录开始的

第二个方法用来设置每页的最大记录数

通过这个就足以实现分页了,先实现了功能再说吧,这样做反正是不太好呵呵

AppleFramework在数据访问控制层采用了Spring Data作为这一层的解决方案,

下面就对Spring Data相关知识作一个较为详细的描述。

1Spring Data所解决的问题

Spring Data :提供了一整套数据访问层(DAO)的解决方案,

致力于减少数据访问层(DAO)的开发量。

它使用一个叫作Repository的接口类为基础,

它被定义为访问底层数据模型的超级接口。

而对于某种具体的数据访问 *** 作,则在其子接口中定义。

public interface Repository<T, ID extends Serializable> {

}

所有继承这个接口的interface都被spring所管理,此接口作为标识接口,功能就是用来控制domain模型的。

Spring Data可以让我们只定义接口,只要遵循spring data的规范,就无需写实现类。

2什么是Repository?

21 Repository(资源库):通过用来访问领域对象的一个类似集合的接口,

在领域与数据映射层之间进行协调。这个叫法就类似于我们通常所说的DAO,

在这里,我们就按照这一习惯把数据访问层叫Repository

Spring Data给我们提供几个Repository,基础的Repository提供了最基本的数据访问功能,

其几个子接口则扩展了一些功能。它们的继承关系如下:

Repository: 仅仅是一个标识,表明任何继承它的均为仓库接口类,方便Spring自动扫描识别

CrudRepository: 继承Repository,实现了一组CRUD相关的方法

PagingAndSortingRepository: 继承CrudRepository,实现了一组分页排序相关的方法

JpaRepository: 继承PagingAndSortingRepository,实现一组JPA规范相关的方法

JpaSpecificationExecutor: 比较特殊,不属于Repository体系,实现一组JPA Criteria查询相关的方法

我们自己定义的XxxxRepository需要继承JpaRepository,

这样我们的XxxxRepository接口就具备了通用的数据访问控制层的能力。

采纳吧

在使用Hibernate时,可以用

querysetFirstResult(130);//设置取值的开始位置

querysetMaxResults(10); //设置读取数据的记录条数

方便的实现分页。

对于hibernateTemplate来说spring在整合hibernate时并没有实现分页。使用spring的hibernateTemplate的回调机制扩展hibernateTemplate的功能实现分页。其中HibernateCallback()是一个接口。

首先  app 第一次请求  你查询前9条数据给他,当app执行上下拉之类的 *** 作时 请求携带 page参数

第一次:

select  from A limit 0,9

第二次 和 以后每次 传来 page (23456789相当于页码)

第一页之前已经有了,这次app传来 page=2

$start = ($page-1)9  //$page 的值是2    $start 是这次从第几条开始查询

select  from A limit $start,9

下一次page=3 依然是上面的查询

以上就是关于java中如何实现分页显示全部的内容,包括:java中如何实现分页显示、如何设计api分页、分页功能设计(解决数据重复问题)等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/web/9353039.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-27
下一篇2023-04-27

发表评论

登录后才能评论

评论列表(0条)

    保存