《订单管理系统（SSH版）》(6)

浪潮优派 订单管理系统(SSH版)技术总结报告

的逻辑，起到一个承上启下和中流砥柱的作用。如果没有它，action会显得臃肿或者dao会显得太操心。

各司其职，Service把处理好的hql和分页参数给dao之后，dao就只负责进行数据库的查询了。通过上一句的叙述，我们可以想到有hql和分页参数，那么不就是用hql实例化一个Query实例，然后为它setFirstResult()和setMaxResults()嘛，似乎无论是代理商还是用户还是客户或者货币的查询来了，dao层的代码都是这样的嘛。这正是由于Service的存在和辛勤工作导致了dao层逻辑瞬间清晰了很多。所以这里调用的dao的查询函数虽然是写的agencyDao的，但是其实是agencyDao和所有实体类Dao的父类BaseDao中的函数，核心代码如下。 通过泛型，让其可以支持更多不同的实体类的查询。反正都是给hql和分页参数的查询，仅仅只是实体类不一样罢了，一个泛型就可以解决的问题嘛。从上图可以看出，真实的代码与上一段分析的一致，实例化Query然后设置分页参数，调用list()方法进行查询，返回一个List。到这里，dao层的任务就已经结束了。本来嘛，dao层就是做数据访问用的，数据访问就是那么单纯，说到底就是连接好数据库然后通过hql进行交流，然而使用了HibernateTemplate或者是使用原生的Hibernate接口，似乎连接的过程也不用程序员去操心了。然后dao层把这个查询出来的结果集返回给Service，再返回给action。这样关于默认的查询的元素部分的查询就结束了，action的agencies属性字段中就保存了从第1条记录开始10条记录的这些Agency代理商实体，这就是默认查询查询出来的结果集的结果。说完了，松了一口气，但是这仅仅只是结果集的查询。回想action中的代码截图，似乎还有两块逻辑没有说。action中的下一个逻辑如下图。

那么下面，还要进行的第二部分的工作，那就是总数的查询。既然都查出前10个元素来了，给用户看不就完了，为么还要查总数。这是因为前台分页和显示当前已查到的记录状态的需要。如果不知道总记录数，只知道页长10，当前

26

浪潮优派 订单管理系统(SSH版)技术总结报告

页是1，又怎么能知道一共应该显示多少个页码标签给用户，用户又怎能单击写有页号的页码标签来实现分页查询。所以，查询总数还是必须的。Action中进行这一个操作的代码就是上面那幅图片中所述的代码了。

依旧调用了Service层的逻辑，但是查询总数传入的参数似乎比查询结果集的参数简单多了。来，再看一下查询结果集时使用的参数。

对比很明显，查询总数只需要代理商名字、业务员名字和状态，这些似乎都只是where子句中的，我们意想，应该就是符合where子句中的这些筛选条件的代理商会被一个个统计计数。然而在查询结果集的时候，还传入了分页和排序相关的，这影响到了用户将会看到哪一个记录区间的记录和以怎样的顺序去看。而统计总数不需要排序不需要分页，排序了也不影响结果，分页了那还哪是总数。讲明白这一点，就知道为什么传这些参数。那么下面调用Service层逻辑，与查询结果集的时候类似，只不过参数少了，如下图。

同样，调用刚才查询结果集的时候调用过的组装参数为hql雏形的方法。上面也有提到该方法之所以只组装where子句，是为了复用，如果该方法中又涉及了排序子句的组装，那么对于统计总数的hql是无法进行复用的。上图中，理所当然的，把属于where子句参数的三个参数传到方法中，返回一个hql雏形。至于雏形啥样，针对是否是默认参数有不同的样子，叙述结果集查询的时候已经进行了很详尽的解析了。

好了，hql雏形有了。对比查询结果集时候的再加工，那时是对order by的加工，那么在统计总数这里不需要order by，排序了也没用，但是需要的聚集函数来统计总数，所以这一模块的再加工就是在hql雏形前面加上”select count(a.id)”，即以id的数目来统计总数，否则不用count聚集函数怎能返回总数。然后调用dao层查询逻辑进行查询，同样，这一个方法也是AgencyDao

27

浪潮优派 订单管理系统(SSH版)技术总结报告

从BaseDao继承而来的，BaseDao中规定了进行数据库访问中一些共用的模块和方法。调用到的这个函数，可以想到的是实例化一个Query，然后调用uniqueResult()返回一个long类型的总数就可以了。当然也可以直接使用hibernateTemplate的find来返回一个List，不过再转比较麻烦。于是实际代码中使用了前者，如下图。

然后得到的long类型的总数count返回给Service返回给action。于是action就知道了当前应该传送给客户哪一些数据，也知道了一共有多少条数据从而前台可以参考它来做分页。action中最后做的，就是根据记录总条数和当前页长，来计算出了页码号的总数，前台直接拿到这个数据进行页码的显示就好了。哎，action还真是操心。如图。

计算分页总数，即记录总条数除以每页中的记录数得出double类型值再向上取整。比如recordCount为11代表一共有11条记录，pageSize为5代表每页显示5条记录，除法运算之后得2.2，如果分页为2页的话，那么第1-10条肯定没问题，但是第11条肯定显示不出来，所以应该ceil()向上取整得3才是最后的答案。

到了这里，服务器端的处理就结束了，知道了结果集，知道了分页参数。然后转向agencyMaster字符串指向的逻辑视图即agencyMaster.jsp。jsp页面中的展现牵扯到了一些前台的部分，毕竟本次项目的主要精力放在后台，给的原始项目模板中前台也编写的差不多了。这样，下面对前台使用struts2标签进行数据展现的部分和分页部分的前台实现进行一些必要的说明。

首先说，对于结果集的展现。服务器勤苦的按照默认参数查询出了第一条记录开始，前十条记录的结果集，或者说干脆说第一页的结果集，前台这时候需要展现服务器的辛勤工作的成果了。如何展现，强有力的方式就是通过struts2的标签，然后使用ognl访问action的值栈。action中的agencies结果集和计算出来的分页数据都在值栈中。如下图，使用s:iterator标签进行遍历。

然后把每一次遍历得到的当前的那个Agency实例放到var指向的agency

28

浪潮优派 订单管理系统(SSH版)技术总结报告

变量中，再一个个抽取它的属性值进行展现。展现输出即使用了s:property标签，然后用s:if标签进行了一些判断以进行参数的必要转换，毕竟有的参数是面向数据库的为了好存储，但是前台不一定好看，即用户不一定很快的看懂，比如数据库寸的isValid为“T”，意思是“有效”，那么前台应该显示哪个？当然现实“有效”了，显示“T”还以为是“Transformer”变形金刚来。所以，有些转换还是很有必要的。如下图，同时展现了这两种标签的作用。 当然那一块s:if的也可以使用s:property并在其中使用三元运算符一个问号一个叹号来决定是显示“有效”还是“无效”，但是该字段中还有一个icon图标，那样做不太方便，所以使用了s:if标签来进行判断以显示不同的状态。

以上说明了结果集的遍历和展现，action中还有分页属性。对于分页的相关属性，前台的处理方式如下。

这一个引入的jsp文件的说明就到此为止。从而知道了from区间左端点和to区间右端点，那么下面只需要把from-to这个左闭右闭区间内的这pageSize个数字给遍历出来，然后以有好的形式展现给用户。这一个展现的过程就是 …… 此处隐藏：2794字，全部文档内容请下载后查看。喜欢就下载吧 ……