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

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

4.3该系统如何工作。

以上结合系统中已做模块的截图对系统的功能层面进行了简要又罗嗦但是必要的说明，看到了系统的外观和它能完成怎样的工作。下面我想对系统内部是如何工作的进行叙述。也是因为在本设计报告模板的第五部分，对于“技术总结”每个部分的标题都很有较强针对性，不太方便单独拿出一块去做这样的叙述，故在这里拿出一块来进行系统内部工作的叙述。

这里直接结合一个具体的例子来叙述一下这个请求响应在客户端和服务器走过了怎样的路线。那就以上边刚写完的“代理商查询”为例，趁热打铁，叙述一下这个流程。下面开始步入正题。

首先，客户端在主菜单界面单击大大的“代理商管理”按钮即可进入这一个功能，回忆前面的功能叙述，用户应该看到的应该是系统默认查询出的第一页的全部代理商的信息。别着急，这个结果的出现还是需要经过一些周折的。下面从用户单击动作开始。下图展现了前台的按钮界面，以及界面背后的代码的真实面目。 从代码可以看出，用户单击按钮后，页面会跳转，跳转的目的地在location猜测一下参数的含义，getAll代表是查询，first代表是第一次查询，第一次的意思是指是主菜单上单击“代理商管理”按钮而引起的默认查询，而不是单击分页的查询或条件查询，所以应该清空action中原有的查询参数采用默认查询。上面对参数的含义进行了猜测。实际实现中，就是如此。

现在还是在前台，当单击事件发生，代码执行，发送请求到了后台。那么这些参数是怎么传递的。答案肯定是参数按照名字进行匹配注入到action中对应的同名属性字段上来的。当然，这些属性字段它们都必须有合法的get和set方法。现在登场的这两个简单的参数对应的action中的属性字段的如下图。

21

后面有描述。即跳转到agencyAction.action这一个action，并且传递了参数。

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

action收到请求，通过purpose参数来分流请求，看看是增删改查中的哪一类请求。当然关于分流请求还有其它多种方式，比如使用DMI动态方法调用提交到不同的方法，这里请求种类并不是很多，就采用这种参数分流的方式吧。那么当action知道当前的请求类型是getAll查询请求的时候，就会走查询逻辑，这时候又发现purposeFlag是first，于是知道了这是从主菜单过来的默认查询请求，所以查询参数置空，这个判断和置空的过程，如下图。

之所以查询参数要置空，是因为要抹除那些非默认查询的参数的干扰，可能在拿个环节会有残余。比如上一次查询可能用户刚经过一次由页码切换或者条件查询引起的查询，action中或者url中还保存着陈旧的参数。而当用户从主菜单单击进入代理商查询的时候，这时候执行的查询应该是默认的查询，如果使用这些旧参数进行查询，那查出来的结果会使用户感到茫然，“咦，怎么默认查出来是这个样子，我没做这样的筛选条件啊”。当然，这样未尝不可，在技术层面上

讲无可厚非，但是更好的还是刚进入这一个查询模块的时候采用默认查询方式。

上图可见，参数都已经初始化为默认值。一串变量初始化为空串，当前页面为1，页长为10，且purposeFlag重置为null，那么下一次请求只要不是主菜单过来的便不会走这个重置参数为默认值的逻辑了，因为purposeFlag不会再为first了。

废话少说，其实也没少说多少，来步入关键的查询逻辑。查询逻辑这里不是

22

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

简单地一个getAll()方法的调用就拍屁股走人，因为这样的getAll()获得全部的逻辑太简单了，这一层调下一层，最后的hql才仅仅是个“from Agency”。虽然这里是默认查询全部，但是在前面的功能讲解中也有看到查询界面中，还有分页查询、排序查询、条件查询等一系列复杂查询，这些查询是会有更多的参数进行控制和约束的。那么为了代码的高复用性和低耦合性，所以使用了相同的查询逻辑。这也是为什么上一段说的查询参数重置为默认值的原因，置空即处理，处理了当然就要用，怎么用，就是把这些参数往公共查询逻辑里面塞，为了代码的复用，只能牺牲上述的参数重置默认值的逻辑来契合公共逻辑的胃口了。那么下图就展现了这些参数的使用和业务逻辑层查询逻辑的代码的调用。 为了不引起介绍逻辑上的混乱，还是以默认值的方式进行默认查询为例，后面再叙述分页查询、排序查询和条件查询的实现，那时候这些参数可能就是千奇百怪，这个后面再说，反正都是调用的相同的逻辑。

看到上图中的三大部分，被绿色注释分隔开。第一部分，按照默认条件去查询了代理商的结果集，虽然是所有的，但是也必须遵守默认条件，默认条件即默认参数，虽然是默认参数但是分页参数却是有值的，分页参数就决定了查询的结果是从第1条开始，长度为10，所以这一句话返回的应该是前10个代理商的结果集给List类型的agencies。既然说到了这个功能，就把它的实现展开说完，下面将叙述代码走到这里是如何一层层调用下去的。它的实现需要调用Service业务逻辑处理层的方法，该方法的方法体如下图。

23

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

业务逻辑层的逻辑主要分为两部分。第一部分，对参数的初步处理，第二部分，调用dao层访问数据库。

首先第一部分，对参数进行初步处理，这里调用了一个方法，由于方法体较长，就不截图了，但是逻辑很简单，一说就明白。这个函数的主要功能就是根据传过来的参数来组装一个hql的雏形，比如采用默认参数的，组装回来的hql就是“from Agency a and 1=1 and 1=1 and 1=1”，意思不就是没有筛选条件的情况下查询所有的记录嘛。因为传给了这个函数有三个参数即分别是name、username和isValid，且每一个都在action中被置为空串，那么经过判断，默认查询全部，为了代码的可复用性，所以这里都被翻译为了“1=1”永真，即传过来的这些条件不起到筛选作用。

不过这样说可能有些故意和矫情，感觉“1=1”加不加都行。那么再举一个有参数的例子，别混乱，这里我们还是说的无参数的情况，只不过借用一个有参数的例子来说明这个hql构造函数的逻辑的可靠性和复用性。如果传入name为“Bob”，传入username为“Tom”，传入isValid为“T”，那么返回的hql的样子是怎样的呢？这里的三个参数肯定是起到筛选作用了，肯定不能再是坑爹的“1=1”了。而且这三个参数的筛选条件还应该同时满足，即“and”来

连接。那么答案就是“from Agancy a and a.name like ’%Bob%’ and a.user.username like ‘%Tom%’ and a.isValid=’T’”，显而易见，原本的“1=1”被三个筛选条件替换了。与事先的分析一样，筛选参数起作用了，并且用“and”来连接。这也是为什么会有“1=1”，既然这个恒等式可有可无为

24

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

什么还要出现三次，这是因为“and”的原因。无论传过来的参数是不是默认，该函数接受了三个参数name、username和isValid，那么无论怎样，首先两个“and”摆上，如果参数不是默认那么让你起到筛选作用填到“and”的空里，如果是默认值筛选参数不起作用，那么就是向“and”的空里填入“1=1”。么？不填行不行？那两个“and”在一 …… 此处隐藏：2367字，全部文档内容请下载后查看。喜欢就下载吧 ……