机房收费系统--总结
2015-04-29 08:02
281 查看
机房收费系统拖拖拉拉进行了好长时间,从最初的数据库设计,到最后的代码运行,将整个C/S重新复习了一遍,这种反复的学习方式让自己收获了很多。
完成规划和需求分析后,先使用E-R图分析系统的概念模型,其组成部分包括实体、联系和属性,为限制实体的数目,限定联系类型的约束,最后要对设计的E-R图实行优化(尽可能少原则:实体个数尽可能少,属性尽可能少,联系无冗余):分裂、合并、增删。(机房收费的数据库设计见《机房收费系统--数据库设计》)
实现E-R图模型到关系模型的转化,完成逻辑设计。使用的是E-R图到关系模式集的算法。
![](https://img-blog.csdn.net/20150429084148860)
关系模式:
系(系编号,系名,电话,主管人的教工号)
教师(教工号,姓名,性别,职称,系编号)
课程(课程号,课程名,学分,系编号)
任教(教工号,课程号,学分)
(注:这里不支持波浪线,外键用红字代替)
先将转化实体,根据1:1,1:N关系确定外键,因为主键唯一,不难得到,是将1对应实体的主键作为N对应实体的外键;M:N的关系,利用联系形成一个新的关系模式,如上面的任教。
设计完成自己的关系模型,要用到三范式来衡量自己模式的好坏。第一范式保证每个属性值都不可再分,第二范式让非主属性完全依赖与候选键,第三范式让非主属性不传递依赖候选键。
自此,根据关系模式,设计表名和字段名称,选择适当的字段数据类型,完成数据库的设计。
对于不满足三范式的字段使用,可通过视图和存储过程的方式来创建使用。(两者的简单实用见上文:《机房收费系统--存储过程、视图》)
![](https://img-blog.csdn.net/20150429094040365)
最初借鉴于师哥师姐们的七层包图设计,根据自己的构想,将B层设计为一个方法一个类,将B层彻底解耦。这样,我们的数据库有9张表的话,每张表实现增删改查,会有36个方法类,另外,增删改查的参数不同,这样36个类还要不止,虽然耦合度大大降低,但方法类过多对于外观层的调用造成困难。
想到改进方法,B层按照数据表的结构进行划分,外观Facade按照窗体的结构进行划分,这样,对B层的方法调用提供了统一的接口,这样更加符合外观模式,进一步规范化;但在代码实现过程中会发现,如果U层代用的B层方法较少的话,Facade层就显得多余,这可能就是外观模式的不足之处吧。
对比于外观,配置文件+反射+抽象工厂的设计方式给系统带来的效益更大,它实现程序与数据库的解耦。当一个用户要想实现SQL和access数据库的切换时,必须要满足二者使用的同一个数据库(字段和表名称完全一致),使用的SQL查询语句一致,但任然存在问题:access是否支持视图和存储过程?access与SQL server对数据结构的操作是否完全一致还有待考证。这种设计方式叫抽象工厂,但其结构已经将抽象工厂改的面目全非。
抽象工厂是一种创建型模式,是站在系统设计的最高角度考虑的设计模式,外观模式属于结构型模式,另外本次使用的模板方法模式是一种行为模式,对这些模式的使用要站在正确的立场去考虑,是属于创建型,结构型还是行为型,这样,模式使用才能更加精确,更便捷的为我们的系统服务。
UML图应用于文档编写过程,是进行合理规划,实现团队合作的必要过程。本次对收费系统的操作,重点对UML的时序图部分进行了研究,从时序图的设计,能够清晰的屡清图与代码的实现逻辑,这样方便我们的分工合作。
UML图和设计模式的使用其实并没有对错之分,只是我们的选择对系统设计带来的便利会有不同,这样就需要我们学会使用更加合适的设计模式与创建过程。
SqlHelper类:创建于D层,实现对访问数据库的增删改查方法的封装
CoverToList类:创建于D层,实现对数据库表格的泛型封装,便于数据传输和使用
Model类:创建于U层,实现诸如Excel调用,判断为空,判断是否为数字等公用方法的创建与重写。它的方法通过Call命令调用。
实体类:单出一层,实现对用户输入数据的采集与传递
那程序中的军纪都有哪些呢?
1. 命名规范:能体现数据实质;能区分变量、控件、常量;体现数据类型;体现变量作用
2.代码格式化:标点符号的使用,空行与缩进,最重要的原则就是保证自己的代码清晰,便于阅读理解
3.注释:开头要注释开发团队、作者、日期、基本描述、版本等基本信息;描述何时可能出错,为什么出错,尤其在需要捕获错误时,描述清楚为什么要捕获;注释的书写规则:完整句子,不缩写,整个单词大写。
【数据库】
第二遍操作系统设计,在之前使用的数据库的影响下,对需求的了解并不陌生,因此对数据库的实现过程相对简单,但缺乏了正规的实现过程。一个数据库的生命周期包括:规划--需求分析--概念设计--逻辑设计--物理设计--实现--运行和维护。完成规划和需求分析后,先使用E-R图分析系统的概念模型,其组成部分包括实体、联系和属性,为限制实体的数目,限定联系类型的约束,最后要对设计的E-R图实行优化(尽可能少原则:实体个数尽可能少,属性尽可能少,联系无冗余):分裂、合并、增删。(机房收费的数据库设计见《机房收费系统--数据库设计》)
实现E-R图模型到关系模型的转化,完成逻辑设计。使用的是E-R图到关系模式集的算法。
关系模式:
系(系编号,系名,电话,主管人的教工号)
教师(教工号,姓名,性别,职称,系编号)
课程(课程号,课程名,学分,系编号)
任教(教工号,课程号,学分)
(注:这里不支持波浪线,外键用红字代替)
先将转化实体,根据1:1,1:N关系确定外键,因为主键唯一,不难得到,是将1对应实体的主键作为N对应实体的外键;M:N的关系,利用联系形成一个新的关系模式,如上面的任教。
设计完成自己的关系模型,要用到三范式来衡量自己模式的好坏。第一范式保证每个属性值都不可再分,第二范式让非主属性完全依赖与候选键,第三范式让非主属性不传递依赖候选键。
自此,根据关系模式,设计表名和字段名称,选择适当的字段数据类型,完成数据库的设计。
对于不满足三范式的字段使用,可通过视图和存储过程的方式来创建使用。(两者的简单实用见上文:《机房收费系统--存储过程、视图》)
【UML图与设计模式】
最初借鉴于师哥师姐们的七层包图设计,根据自己的构想,将B层设计为一个方法一个类,将B层彻底解耦。这样,我们的数据库有9张表的话,每张表实现增删改查,会有36个方法类,另外,增删改查的参数不同,这样36个类还要不止,虽然耦合度大大降低,但方法类过多对于外观层的调用造成困难。
想到改进方法,B层按照数据表的结构进行划分,外观Facade按照窗体的结构进行划分,这样,对B层的方法调用提供了统一的接口,这样更加符合外观模式,进一步规范化;但在代码实现过程中会发现,如果U层代用的B层方法较少的话,Facade层就显得多余,这可能就是外观模式的不足之处吧。
对比于外观,配置文件+反射+抽象工厂的设计方式给系统带来的效益更大,它实现程序与数据库的解耦。当一个用户要想实现SQL和access数据库的切换时,必须要满足二者使用的同一个数据库(字段和表名称完全一致),使用的SQL查询语句一致,但任然存在问题:access是否支持视图和存储过程?access与SQL server对数据结构的操作是否完全一致还有待考证。这种设计方式叫抽象工厂,但其结构已经将抽象工厂改的面目全非。
抽象工厂是一种创建型模式,是站在系统设计的最高角度考虑的设计模式,外观模式属于结构型模式,另外本次使用的模板方法模式是一种行为模式,对这些模式的使用要站在正确的立场去考虑,是属于创建型,结构型还是行为型,这样,模式使用才能更加精确,更便捷的为我们的系统服务。
UML图应用于文档编写过程,是进行合理规划,实现团队合作的必要过程。本次对收费系统的操作,重点对UML的时序图部分进行了研究,从时序图的设计,能够清晰的屡清图与代码的实现逻辑,这样方便我们的分工合作。
UML图和设计模式的使用其实并没有对错之分,只是我们的选择对系统设计带来的便利会有不同,这样就需要我们学会使用更加合适的设计模式与创建过程。
【程序实现】
本次机房重构,给自己最大的体会是要学会将重复代码封装。最经典的使用便是实体层的应用,SqlHelper类的创建,CoverToList(转换为泛型集合)类的使用,还有在U层创建的model实现对一些公用方法的封装。SqlHelper类:创建于D层,实现对访问数据库的增删改查方法的封装
CoverToList类:创建于D层,实现对数据库表格的泛型封装,便于数据传输和使用
Model类:创建于U层,实现诸如Excel调用,判断为空,判断是否为数字等公用方法的创建与重写。它的方法通过Call命令调用。
实体类:单出一层,实现对用户输入数据的采集与传递
【规范化问题】
一个训练有素的军队,必定有一整套成文的军纪;编程也是一样,掌握这种规范化的编程规则,必定事半功倍。那程序中的军纪都有哪些呢?
1. 命名规范:能体现数据实质;能区分变量、控件、常量;体现数据类型;体现变量作用
2.代码格式化:标点符号的使用,空行与缩进,最重要的原则就是保证自己的代码清晰,便于阅读理解
3.注释:开头要注释开发团队、作者、日期、基本描述、版本等基本信息;描述何时可能出错,为什么出错,尤其在需要捕获错误时,描述清楚为什么要捕获;注释的书写规则:完整句子,不缩写,整个单词大写。