实验室设备管理系统项目总结(1)——Model层

c++出身的我自从开始接触编程以来就很少做过其他语言的项目,而且一直做的也基本上是关于VC的,所以对于VC的各个方面也算是有一定的经验积累,而京城和我一块做项目的人或是不肯露出自己的“本事”,或是很菜,所以慢慢的我自大起来。但是 最近两个月一直在做一个关于JSP的实验室设备管理系统,遇到了各种问题,可谓是麻烦缠身,本来以为一个月就可轻松搞定的项目,结果做了两个多月一直拖到现在才勉强结束。在这个过程中,我慢慢地转换过来了心态,开始不在鄙夷JAVA语言的使用者了,开始深深地为他们成功完成的项目而惊讶。

刚一开始,我准备使用MV模型的开发模式,即JavaBean+JSP,所以在第一周我就开始了自己的底层构建,完成了数据字典的抽取,数据字典如下表所示:

表1-1----数据字典表

 

数据结构名

包含数据项

数据项名

数据类型

取值含义

 

 

设备

类别信息

类别名

文本串

设备所属的种类的名称(包括种类),比如说摄像头、工具、采集卡、开发板、开发箱等,其中包含了品牌

类别号

数字

类别的编号

库存数量

数字

该设备库存的数量

借出数量

数字

该设备已被借出的总量

 

设备状况信息

设备状况号

数字

设备状况信息的编号

设备状况

文本串

设备目前的状况,如良好,损坏等

 

设备状态信息

 

设备状态号

数字

设备状态信息的编号

设备状态

文本串

设备目前的状态,如借出,未借等

 

 

 

 

 

设备

基本信息

设备编号

字母数字串

每个设备的唯一编号

类别号

数字

设备类别的编号

设备状态号

数字

描述设备状态信息的编号

设备状况号

数字

描述设备状况信息的编号

规格型号

数字字母串

就是关于型号,规格的一种编号说明

制造厂名

文本串

制造设备的厂家

出厂日期

日期

一般是指设备入库的日期

出厂机号

文本串

每个设备出厂时的编号

单位

文本串

设备的计量单位

单价

浮点型

每件设备的单价

附件及有关说明

文本串

设备附加说明,比如电脑有屏幕尺寸,CPU型号,硬盘,内存等

设备照片路径名

字符串

设备入库时拍摄的照片的路径的字符串

入库建账信息照片路径

字符串

设备入库时拍摄的入库建账单的照片的路径的字符串

 

 

 

 

 

用户信息

用户信息编号

数字

用户信息的编号,无实际意义

用户名

字母数字串

用户的登录名(可以外加验证,保证唯一,作为主键)

密码

字母数字串

用户登陆的密码

姓名

文本串

用户姓名

用户类别

布尔型

真代表是普通用户,假代表是高级用户

所在部门

文本串

用户所在的部门

负责老师

文本串

负责管理用户的老师

 

 

 

 

 

借还信息

设备编号

字母数字串

每个设备的唯一编号

借出时状况

文本串

借出时设备的状况,即良好或损坏

借出日期

日期

 

借出人姓名

文本串

借出设备的人的姓名

借出管理人

信息号

数字

借出时值班的人的信息号,此人负责检查设备的状况已记填写相关信息

归还时状况

文本串

归还时设备的状况,即良好或损坏

归还日期

日期

 

归还管理人

数字

归还时值班的人的信息号,此人负责检查设备的状况已记填写相关信息

借用人照片路径

图片

借用人借设备时拍摄的照片的路径的字符串

同时完成了数据库表格的建立,并施以相应的完整性约束,各表如下所示:

                                   

这个时候我在思考如果在借设备的时候,需要在插入借还信息的同时更新的数据有设备的状态,某类设备的库存量以及借出量,需要执行三条语句,也不方便后期MV模型的使用,因此决定使用触发器来实现这一功能,于是就分别添加了四个触发器:添加设备(设置状态为未借,状况为良好,因为只有状况良好的设备才能入库,而且设备入库后的状态肯定是未借,并判断是否是新种类的设备,如果是新种类设备,则在设备种类表中新加一列),添加种类(设置当前种类设备的库存量为1,借出量为0),借用设备(设置设备状态为已借,设置该类设备的库存量减一,借出量加1,并设置归还日期为默认值),归还设备(判断更新信息前设备的归还日期是否小于借用日期,若小于则表明是归还操作,这时将设备状态设为未借,并更新该类设备的库存量与借出量)。但是触发器并没有经过严格的测试,不是太稳定,因此为后期的调试增添了不少的麻烦。这也让我深刻体会到了单元测试的必要性。随后便使用之前的现成类系统构建数据库操作底层类,而后又将数据库中每个表格对应的实体信息类添加进来,到此为止数据库相关的工作暂时告一段落。

接下来,依据功能需求又针对每类信息添加了各自所需的业务类,至此模型层构建完毕。但是在此过程之中,我过于追求速度,看着代码类似就一个写好后其他的地方都拷贝,整个下来由于拷贝所造成的调试负担让我极为后悔,这也让我体会到了那些软件大师所说的Don't Repeat Yourself的DRY原则。小型的程序可以拷贝,但是在大型项目里是绝对不允许拷贝出现的,因为一处更改以后需要耗费大量的精力去保证其他各处有无修改,而且后期调试找出这个Bug可谓是难上加难,当然我做的这个并不是大项目,只是我把好多东西都做得太类似,因此可以拷贝的地方很多很多,故而会出现那种情况。为了以防万一,我在大部分代码之中都加入了ISO-8859-1转码方法用于解决乱码问题。

你可能感兴趣的:(技术笔记)