【机房收费系统】磕磕绊绊中总结

前端之家收集整理的这篇文章主要介绍了【机房收费系统】磕磕绊绊中总结前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

每一个庞然大物来之前,总是心里不自觉的退缩一下。这一次,把我自己当成了奥特曼。

命名规范文档

最先看的是这个。有了标准后,才能见其名 知其意。

数据库设计

敲完三层登陆小demo,这一次重新着手,从ER图开始设计数据库。又翻了翻自考的书,把机房收费系统中可能抽出来的实体画出来 又开始一个个找联系。转换为逻辑结构。可能根据业务的不同,表和主键会稍微有些变化。比如,是否允许一个学生有多张卡,退卡之后原来的卡号还能否再注册,退卡是是否要删除记录等修改添加一些辅助标记字段,也涉及到一些其他问题,例如添加用户 是谁添加等 要不要做记录。 基本按三范式来的,然后想到一些涉及到多表的,又加了一些视图。

画图

之后,画图的时候,一开始自己想 抽象工厂和映射怎么加?怎么听说还有外观?sqlhelper又是什么?虽然大家都说网上这种资料一大筐,可是,总觉得学完了设计模式,应该自己试着加加。又憋了一小阵,也无从下手,心情不美丽了。师傅给指导了两次才开始才开始转变自己的想法,开始站在巨人的肩膀上。这个阶段开始学着使用EA,开始理解着各层的协作配合。从网上查,看人家的 学着理解。外观按功能分,其他按表分类,一开始BLL层的时候,还加这某视图类,说明自己当时还不够通。

实现中

把之前听说的抽象工厂和外观,sqlhelper都用上 ,实现了一个传说中的7层架构。又用断点调试理了理思路。想着一想,七层无非还是三层。一涉及到新的用法就要上网查,不过相似的功能也越理越明白了。

实现中也没有一帆风顺,不过就像当初捣鼓数据库的时候,也是出了很多错。现在弄明白了,就再也拌不住自己了。

关于传实体还是传其他

一开始,听说不让用datatable。于是我在敲之前,先用datatable做了一个demo。也就对所说的解耦,各层相互调用不方便有了初步了理解。后来就重点在理解传实体了。现在各层之间,有返回Boolean的情况,也有参考他人的将datatable转换到list中。

当涉及到查询视图,返回两个或多个实体的属性时,想到了以下几种方法

一:最不用动脑子的

就是分别查,然后分别赋给每一个实体。只是 代码就多了。

二:做一个联合实体类。属性包含两个基础实体的所有属性。我想,如果是用C++,是不是来个多重继承也不费事。可是vb.net不支持哇。

三:超哥告诉我的,可以在参数中改为byref。返回一个实体,隐含传另一个实体属性。或干脆隐含传两个实体。

不过也有遇到了还不知道怎么解决的,比如注册时,外观判断学号是否存在,判断卡号是否存在,那返回的就有3中情况。这会返回整型不合适吧?若是返回两个实体类型,那外观是不是又是多余的了

关于数据库

数据库字段和实体属性不对应

查询语句中给数据库字段还可以起小名。例如 select userName as strUserName

“未将对象设置引用到对象的实例。”

先看看是不是提示出 除接口之外的类型是不是在实例化的时候 没有用“new”,另一种情况,看看数据库的操作语句能不能在数据库中操作。(当然还有最常出现的如果还不行,再转换实体类处加断点, 再看看是不是由datatable到list的转换出了问题。

必须声明标量变量

查询数据库中不存在的字段

截断字符

由于数据库中数据超过了定义的空间大小

小经验

再哪里设置断电 是一件有意思的事。

更改后的文件,最好重新编译一下,不然有时候还是执行的修改前的解决方案。

比如 对非共享成员的引用 要求对象引用。也是很常见的。

后来也试着在EA中,生成实体代码。至少少了一点重复性的工作,有木有。

*************************************机房进行中,总结积累中。待续*************************************

但是,我常常很纠结,觉得直接拿过现成的是不是太水。后来跟其他同学交流后改变了我当时的想法,这个阶段囫囵吞枣,先从模仿开始,多去做 在做的过程中去理解。是应该这样的么?

猜你在找的VB相关文章