又一次机房收费系统，有一次总结，第一次是vb6，这次则采用VB.NET+设计模式+三层。
vb6的机房收费系统是面向过程开发，代码量大，不易维护，而这次的VB.NET则是面向对象的开发，代码量虽然没有减少反而增多，但是系统的结构变得灵活的多，可维护性增强了不少，采用了分层和设计模式，对象化了各个模块，复用率也大大提高了。
具体来说一下吧。在网上查了资料，简单了解了三层后，开始了我的三层之旅。先用EA画了3层的登录例子。下面是我的系统架构（包图）:
当时一开始只有UI、BLL、DAL感觉太单调了，而且灵活性也太差，感觉系统呆板，所以采用了抽象工厂+反射+配置文件来提高业务与数据库操作的灵活性。单单一个反射，花费了我近2天的时间，最终发现路径下没有反射的对象，把D层生成的dll放到U层Debug中即可反射成功，因为需要D层还需要继续编码，所以在U层对D层添加了引用，这样在每次编译时，可以重新编译D层，而且由于添加了引用，D层的dll会自动复制到U层的Debug文件夹中。
既然是涉及到数据库的开发，数据库的操作是不可避免的，每一个对数据库的增删改查，都需要调用一些固定的方法，工作重复很多，所以就把对数据库公共方法提取出来，作为了新的一层，每个D层的操作都是调用SqlHelper来实现的。这样减少了大量重复性的工作，复用率。。。你懂的。
在写代码的前，向德鹏咨询了一下这么多层，怎么写代码，先写哪个后写哪个？感觉不要对3层单独写完一个再写一个，还是应该按功能模块3层并齐写。以后的合作开发肯定是要分开写的，但是这次开发是个人开发，而且还是第一次写分层的代码，分功能3层一块写，边写边调试，可以及时的发现错误。对于一个功能模块来说我的顺序是先写D层，然后写U层，然后写B层。这样逻辑上上会好很多。
机房收费系统是在这个登录实例上扩展的。本质上是一样的。就是多写了几个功能模块而已。除了报表纠结了1天外，没遇到什么大问题。这次写代码本来差不多应该一周完成的，结果用来10天，主要是当时的时序图没有好好考虑，许多判断都是写代码时才加上的。浪费了不少时间。
当然做完以后，还是感觉做的不好。
比如说DAL层，应该是根据数据库中的表来构造的，也就是根据实体类来设计的。但是在写代码的过程中发现它们除了实体类不一样，其他大部分都很类似，甚至结构一模一样，如果一个地方错误，那全部都得改。昨天跟云姐也讨论了一下，她提出一个观点来——用泛型。针对于实体类，用object来代替，然后通过分析、抽象、融合来重新设计D层，来达到简化D层，减少代码量，提高复用率和可维护性。不过差异性还是存在的，重新设计是需要再仔细琢磨和推敲才能验证其可行度。
对于SQLHelper类，也有争议。如果说SQLHelper类是作为类库而为其他组件复用的画，那么它就可以属于一个组件，而组件应该放在构建图中而不是包图中的。如果说SQLHelper只是为了让D层调用，那完全可以把它放到D层中。所以说SQLHelper作为单独的一层，有争议。
还有许多疑问：D层按数据库表设计，而U层则按用例设计，那么B层按什么设计？？按表？按用例？按业务？？如果按表走，那么B层一个实体类对应一个B层类，但是像充值功能则至少需要操作2个表（卡信息，充值记录），而这个表对应在B层的类又是分开的了，那么B层的逻辑怎么处理？添加一个外观层？？那B层又有什么用？外观层岂不成了业务逻辑层了？？如果按用例，那需要的用例粒度不能太大了，否则在B层会遗漏。按业务，还需要再琢磨。
这次机房收费系统就暂告一段落，期待合作开发能解决这些问题。也期待大家能给我答疑，不甚感激。