OEA ORM中的分页支持
本篇博客主要描述分页的常见技术方案,以及在 OEA 框架中的分页的应用及实现原理。
分页的几种方案
分页是解决大数据量显示的有效方法。根据分页技术应用的位置不同,大致可以把分页分为以下几种:
- 界面层分页
界面层的分页,类似于界面的虚拟化技术,是只显示需要的数据的一种技术。OEA 的 WPF 界面中目前已经实现了 UI 虚拟化,所以不再实现界面层分页。
优点:
* 简单。许多控件都支持在界面层直接进行分页。
* 换页时,响应快。(在 C/S 结构下使用这种方案,数据都已经到达客户端,所以在分页时不需要额外的数据查询,响应速度较快。)
缺点:
* 不用于太大的数据分页。由于没有减少网络传输,首次加载时较慢,需要把所有数据都传输到客户端。
- 实体层分页
在实体层进行分页操作的方案,很少会被使用。它是把查询出来的数据,在服务器端都转换为实体,然后再找到具体页的实体数据,其它的数据则直接丢弃。
优点:
* 减少了首次的网络传输,对于客户端而言,调用的是分页的 API。
* 简单。
* 通用性强,与数据库无关,方案可以跨多种数据库。
* 统计总行数不需要发起二次查询。
缺点:
* 占用内存,依然不能用于太大的数据分页。
- 数据层分页
这种方案一般使用 IDataReader 实现。查询的 SQL 依然是查询所有的数据,但是在对查询出的 IDataReader 进行遍历读取每一行时,只读取对应页的数据,其它页的数据则忽略。同时,遍历到记录集的最后一行,即可获得数据的总行数。
优点:
* 不占用大量内存。只把需要的数据读取到内存中。
* 简单。
* 通用性强,与数据库无关,方案可以跨多种数据库。
* 统计总行数不需要发起二次查询。
缺点:
* 查询的 SQL 会查询很大的一张表。遍历依然需要耗费一定的时间。
- 数据库分页
分页的最终方案,自然是在数据库中进行分页。这也是大多数情况会选用的方案。
优点:
* 性能最好。速度快、占用内存小。
* 统计行数时,往往需要重新发起查询。
缺点:
* 对于框架开发而言,要生成分页相关的 SQL,较麻烦。
* 方案与特定数据库相关。通用性低。
虽然提到了这几种不同层面的分页方案。但是对应应用开发而言,数据库的分页是最常用的。只是在做 OEA 框架开发时,由于要支持多种数据库,所以需要在合适时采用不同的方案。同时,也不会考虑使用存储过程来辅助分页。
OEA 分页 - 应用层接口
在说明 OEA 的分页前。先介绍一个 PagingInfo 类型(老版本中,该类名为 PagerInfo),这关系到整个分页方案的接口设计:
图1 位于 Common(原 hxy)程序集中的 PagingInfo 类型
图2 PagingInfo 类型接口
在查询数据时,我们指定了查询的具体页码 PageIndex、一页所含数据行数 PageSize,就可以把该页的数据显示在界面上了。但是,在分页时,往往要在界面中显示一个分页脚,用于显示当前页号、所有页数。所以在进行查询的同时,往往还需要对结果集中所有数据的总行数进行统计,并把之与查询出的实体列表数据一同返回。所以,我为 PagingInfo 添加了额外的两个属性,IsNeedCount、TotalCount,当 IsNeedCount 被设置为真时,框架在数据层进行查询时,会把统计出来的总行数赋值给 TotalCount。
OEA 分页 - 使用方法
下面以分页查询所有数据为例,简单说明如何使用分页查询。先是应用层使用的代码:
应用层需要构造 PagingInfo,并指定需要统计行数。查询后,直接使用 PagingInfo.TotalCount。(这种接口方案从 06 年使用至今,比较好用。)
下面是 Repository 类型上的公有接口:
最后,再实现该查询对应的数据层即可:
可以看到,在数据访问层的 ORM 框架中,主要是在 IQuery 条件类型上添加了一个 Paging 方法。使用这个方法指定了 PagingInfo 后,即按给定的分页信息分页查询实体数据了。
OEA 中的数据层分页实现
OEA 中用到的分页有:界面层分页、DataReader 分页、数据库分页。
- 界面层分页
其实在 OEA 中就是 UI 虚拟化。相关内容,可以查看《OEA 中 WPF 树型表格虚拟化设计方案》 及 《 精通 WPF UI Virtualization》。
- 数据库分页(分页SQL)
目前,OEA 已经支持了 SqlServer 2005+、Oracle 10+、SqlCE4+,但是框架的设计目标则是应对所有数据库(接下来很可能需要对 MySql 进行支持)。这三种数据库中,OEA 只支持前两种大型数据库的数据库分页,主要是生成分页 SQL 进行查询。
经过对比、挑选,我选用了一种可以在 SqlServer、Oracle 上的一种通用方案,即使用 RowNumber。例如,如果一个 SQL 查询是:
select ...... from ...... order by xxxx asc, yyyy desc
,则只需要把它转换为以下格式就行了:
select * from (select ......, row_number() over(order by xxxx asc, yyyy desc) _rowNumber from ......) x where x._rowNumber<10 and x._rowNumber>5 。
同时,当需要统计总行数时,数据层会生成 SELECT COUNT(0) FROM ...... 的 SQL 语句重新进行查询,并把结果赋值给 PagingInfo.TotalCount,以及 EntityList.TotalCount。
在 SQLCE 中,并不支持 rowNumber 函数。所以只能考虑使用 NOT IN 的 SQL 方案。其实在OEA中,鉴于实现 NOT IN 方案比较麻烦,所以决定暂时使用 DataReader 完成 SQLCE 的内存分页。
- DataReader 内存分页
提供 DataReader 方案主要是简单、同时还能与数据库无关,解决跨库问题。主要逻辑代码如下:
/// <summary>
///使用 IDataReader 的内存分页读取方案。
///
///注意!!!
/// 此方法中会释放 Reader。外层不能再用 Using。
/// </summary>
/// <param name="reader"></param>
/// <param name="rowReader">每一行数据,会调用此方法进行调取。</param>
/// <param name="pagingInfo">分页信息。如果这个参数不为空,则使用其中描述的分页规则进行内存分页查询。</param>
public static void MemoryPaging(IDataReader reader, Action<IDataReader> rowReader, PagingInfo pagingInfo = null)
{
bool isPaging = pagingInfo != null;
bool needCount = isPaging && pagingInfo.IsNeedCount;
int totalCount = 0;
int startRow = 1;//从一开始的行号
int endRow = int.MaxValue;
if (isPaging)
{
startRow = pagingInfo.PageSize * pagingInfo.PageIndex + 1;
endRow = startRow + pagingInfo.PageSize - 1;
}
using (reader)
{
while (reader.Read())
{
totalCount++;
if (totalCount >= startRow)
{
if (totalCount <= endRow)
{
rowReader(reader);
}
else
{
//如果已经超出该页,而且需要统计行数,则直接快速循环到最后。
if (needCount)
{
while (reader.Read()) { totalCount++; }
break;
}
}
}
}
}
if (needCount)
{
pagingInfo.TotalCount = totalCount;
}
}
通用,又简单。
待改进点
目前实现上,可能存在的缺陷是:
- 对分页 SQL 的转换不支持复杂的嵌套 SQL。这时可能出错。
希望大伙拍砖。