c++出身的我自从开始接触编程以来就很少做过其他语言的项目,而且一直做的也基本上是关于VC的,所以对于VC的各个方面也算是有一定的经验积累,而京城和我一块做项目的人或是不肯露出自己的“本事”,或是很菜,所以慢慢的我自大起来。但是 最近两个月一直在做一个关于JSP的实验室设备管理系统,遇到了各种问题,可谓是麻烦缠身,本来以为一个月就可轻松搞定的项目,结果做了两个多月一直拖到现在才勉强结束。在这个过程中,我慢慢地转换过来了心态,开始不在鄙夷JAVA语言的使用者了,开始深深地为他们成功完成的项目而惊讶。
刚一开始,我准备使用MV模型的开发模式,即JavaBean+JSP,所以在第一周我就开始了自己的底层构建,完成了数据字典的抽取,数据字典如下表所示:
表1-1----数据字典表
数据结构名 | 包含数据项 | ||
数据项名 | 数据类型 | 取值含义 | |
设备 类别信息 | 类别名 | 文本串 | 设备所属的种类的名称(包括种类),比如说摄像头、工具、采集卡、开发板、开发箱等,其中包含了品牌 |
类别号 | 数字 | 类别的编号 | |
库存数量 | 数字 | 该设备库存的数量 | |
借出数量 | 数字 | 该设备已被借出的总量 | |
设备状况信息 | 设备状况号 | 数字 | 设备状况信息的编号 |
设备状况 | 文本串 | 设备目前的状况,如良好,损坏等 | |
设备状态信息
| 设备状态号 | 数字 | 设备状态信息的编号 |
设备状态 | 文本串 | 设备目前的状态,如借出,未借等 | |
设备 基本信息 | 设备编号 | 字母数字串 | 每个设备的唯一编号 |
类别号 | 数字 | 设备类别的编号 | |
设备状态号 | 数字 | ||
设备状况号 | 数字 | 描述设备状况信息的编号 | |
规格型号 | 数字字母串 | 就是关于型号,规格的一种编号说明 | |
制造厂名 | 文本串 | 制造设备的厂家 | |
日期 | 一般是指设备入库的日期 | ||
出厂机号 | 文本串 | 每个设备出厂时的编号 | |
单位 | 文本串 | 设备的计量单位 | |
单价 | 浮点型 | 每件设备的单价 | |
附件及有关说明 | 文本串 | 设备附加说明,比如电脑有屏幕尺寸,CPU型号,硬盘,内存等 | |
设备照片路径名 | 字符串 | 设备入库时拍摄的照片的路径的字符串 | |
入库建账信息照片路径 | 字符串 | 设备入库时拍摄的入库建账单的照片的路径的字符串 | |
用户信息 | 用户信息编号 | 数字 | 用户信息的编号,无实际意义 |
用户名 | 字母数字串 | 用户的登录名(可以外加验证,保证唯一,作为主键) | |
密码 | 字母数字串 | 用户登陆的密码 | |
姓名 | 文本串 | 用户姓名 | |
用户类别 | 布尔型 | 真代表是普通用户,假代表是高级用户 | |
所在部门 | 文本串 | 用户所在的部门 | |
负责老师 | 文本串 | 负责管理用户的老师 | |
借还信息 | 设备编号 | 字母数字串 | 每个设备的唯一编号 |
借出时状况 | 文本串 | 借出时设备的状况,即良好或损坏 | |
借出日期 | 日期 |
| |
借出人姓名 | 文本串 | 借出设备的人的姓名 | |
借出管理人 信息号 | 数字 | 借出时值班的人的信息号,此人负责检查设备的状况已记填写相关信息 | |
归还时状况 | 文本串 | 归还时设备的状况,即良好或损坏 | |
归还日期 | 日期 |
| |
归还管理人 | 数字 | 归还时值班的人的信息号,此人负责检查设备的状况已记填写相关信息 | |
借用人照片路径 | 图片 | 借用人借设备时拍摄的照片的路径的字符串 |
同时完成了数据库表格的建立,并施以相应的完整性约束,各表如下所示:
这个时候我在思考如果在借设备的时候,需要在插入借还信息的同时更新的数据有设备的状态,某类设备的库存量以及借出量,需要执行三条语句,也不方便后期MV模型的使用,因此决定使用触发器来实现这一功能,于是就分别添加了四个触发器:添加设备(设置状态为未借,状况为良好,因为只有状况良好的设备才能入库,而且设备入库后的状态肯定是未借,并判断是否是新种类的设备,如果是新种类设备,则在设备种类表中新加一列),添加种类(设置当前种类设备的库存量为1,借出量为0),借用设备(设置设备状态为已借,设置该类设备的库存量减一,借出量加1,并设置归还日期为默认值),归还设备(判断更新信息前设备的归还日期是否小于借用日期,若小于则表明是归还操作,这时将设备状态设为未借,并更新该类设备的库存量与借出量)。但是触发器并没有经过严格的测试,不是太稳定,因此为后期的调试增添了不少的麻烦。这也让我深刻体会到了单元测试的必要性。随后便使用之前的现成类系统构建数据库操作底层类,而后又将数据库中每个表格对应的实体信息类添加进来,到此为止数据库相关的工作暂时告一段落。
接下来,依据功能需求又针对每类信息添加了各自所需的业务类,至此模型层构建完毕。但是在此过程之中,我过于追求速度,看着代码类似就一个写好后其他的地方都拷贝,整个下来由于拷贝所造成的调试负担让我极为后悔,这也让我体会到了那些软件大师所说的Don't Repeat Yourself的DRY原则。小型的程序可以拷贝,但是在大型项目里是绝对不允许拷贝出现的,因为一处更改以后需要耗费大量的精力去保证其他各处有无修改,而且后期调试找出这个Bug可谓是难上加难,当然我做的这个并不是大项目,只是我把好多东西都做得太类似,因此可以拷贝的地方很多很多,故而会出现那种情况。为了以防万一,我在大部分代码之中都加入了ISO-8859-1转码方法用于解决乱码问题。