VB.NET机房收费系统总结

      又一次机房收费系统,有一次总结,第一次是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层会遗漏。按业务,还需要再琢磨。

     这次机房收费系统就暂告一段落,期待合作开发能解决这些问题。也期待大家能给我答疑,不甚感激。
已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 猿与汪的秘密 设计师:上身试试 返回首页