每一个庞然大物来之前，总是心里不自觉的退缩一下。这一次，把我自己当成了奥特曼。
命名规范文档
最先看的是这个。有了标准后，才能见其名 知其意。
数据库设计
敲完三层登陆小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中，生成实体代码。至少少了一点重复性的工作，有木有。
*************************************机房进行中，总结积累中。待续*************************************
但是，我常常很纠结，觉得直接拿过现成的是不是太水。后来跟其他同学交流后改变了我当时的想法，这个阶段囫囵吞枣，先从模仿开始，多去做 在做的过程中去理解。是应该这样的么？
【机房收费系统】磕磕绊绊中总结,布布扣,bubuko.com