很长一段时间没有更新博客,因为前一阵子被项目中的一个模块卡了好久.中间出现了很多问题,解决后又出新新的问题.过程可以说是十分曲折.这里也是做一下简单的总结.
功能简述
强检器具可以被标准器具检定, 现在我们需要按条件查询具有检定能力的器具.由于之前是没有器具检定能力统计的实体的,所以我们需要通过器具, 标准装置来计算对应的查询条件是否具有检定能力,然后将新的数据存入一张新建的数据表中,供查询使用.
难点
1.数据写入
这里的第一个难点是逻辑的复杂.由于器具检定能力统计设计到多个相关联的实体,然后还需要通过关联的实体计算得自己的字段值,所以写入过程较为复杂.
数据写入的流程图如下:
首先获取所有的区域,然后按区域进行授权检定项目的初始化,将所有获取到的区域遍历一遍,获取每个区域上的授权检定项目,并按照器具类别进行分类.
将所有的授权检定项目初始化完后,我们需要计算器具的检定能力,根据不同的区域,计算不同区域上的器具检定能力.
第二个难点是数据量庞大.在我们的系统中,有上千条数据,以后还会有更多的数据.又经过上面的复杂处理,前台的后台访问的时候,就出现了500的报错.错误原因就是读取超时.这个问题我会在后面的博客中做详细的讲解.
2.数据读取
这个部分的难点其实并没有数据写入的复杂,但是由于我自己对于项目的功能的理解出现了点偏差,加大了问题的难度.
器具的分类
首先的一个问题是这个器具检定能力的查询,他有几种查询方式,通过查询的参数不同,需要以不同的属性对其分类.比如:
这个问题我想到了两种解决办法.
第一种是后台写一个方法,获取传入的参数,然后根据传入的参数判断这个这个查询应该以哪个参数进行分类.
第二种方法是前台通过点击查询条件判断传入的参数,然后调用不同的函数,每个函数对应不同的分组.
这两种解决方法我选择了后者,原因的后者的处理更加方便了,虽然写了多个方法,但是逻辑处理更加简单.
3.解决问题中遇到的问题
遇到的最大的问题是read time out,读取超时.这个问题是由于前台发起http请求访问后台,调用后台相应的方法.但这个方法长时间没有放回数据给前台,超过了前台等待的最大时间.
解决办法
我们程序运行慢,很大程度上的瓶颈是出现在数据库的IO上,所以,想要减小程序的运行时间,就可以减小访问数据库的次数.
返回数据中有两个参数,一个是器具总数,一个是受检总数.
在获取器具总数的时候,调用了一个统计的方法,每次查询的每个分组都会调用一次这个方法,而这个方法每次执行都需要访问数据库,无疑为程序带来了很大的压力.所以解决的办法就是一次将所有的器具都获取出来,然后分组以后,每个分组都是一个 List<> ,器具总数也就是List的size.
在获取受检总数的时候,需要判断器具是否具有检定能力,而这是有个变量来表示的,为true表示这个器具具有检定能力.开始获取的时候,也是每次都调用一个方法,然后方法中查找检定能力为true的器具,同样的,这回多次访问数据库.解决办法同上,将所有的器具都获取出来,然后在分组后直接判断这个器具的对应字段是否为true,如果是,受检总数加一.
总结
这个模块的部分处理的时间有点长了,也是出于对这个模块没有充分的理解,做了很多不必要的做功.但不得不说,在处理一个又一个的问题的时候,收获还是不小的.
