机房收费系统重构初期问题总结

Posted 2020-09-14

    进入五月份開始的三层架构的学习。那个时候，三层仅仅是理解了一些理论知识。还有在师父验收三层登陆实例的时候，仅仅知道三层是怎样建立起来的。

并且在验收的过程中，发现非常多逻辑性的错误。三层结束到机房重构，之间不知道停顿了多久。总之，真正開始重构的也就一个星期左右。

    在三层结束之后，就要谋划机房重构的问题了。

可是，对于已经学习了非常多理论知识之后。发现，对于要開始重构机房一点思路都没有。不知道是先从哪里下手，文档？UML图？程序？这样的感觉真是……

    查看tgb的培养计划。从让导师指导建模開始。

也就是先从绘图開始吧。

因为大脑不够用，也就边绘图。边实现吧。最早完毕的图。就是包图了。期间，也让师父指导过。也以前指出过。我在重构机房之间，须要了解一下SqlHelper，在重构的过程中，肯定会使用的。

也查过sqlHelper的用途，可是怎样使用，还是须要去实践的。以下说说遇到的几个问题吧。

 

数据库连接问题：

    在開始进入该阶段開始学习的之后。花费时间长的地方---数据库。停顿时间较长的一部分。就是数据库的链接上，曾经都是通过sqlconnection sqlcommand 等 直接连接数据库的。并且在使用的过程中常常有SQL Injection的攻击。使得数据的安全性就没有了保障。所以開始使用Parameter进行參数查询。

    可是仅仅有发现，有非常多使用sqlAdapater DataSet等也能够连接数据库，这里有非常多历史遗留问题，须要再次开发。

 

SqlHelper问题：

    在只唯独一个登陆实例的情况下，的确是没有必要使用sqlHelper的。可是在一个系统其中。须要频繁的连接数据库。增删改查等操作。

对于美丽的代码。无非就是降低反复。在D层中，把跟数据库连接，运行sql语句有关的大量代码封装起来。这个类就叫做sqlHelper。

    这个问题，乍一看“没问题，挺简单的”。

再一看“这玩意儿怎么写啊，好麻烦”。

再看“这就没啦，没多少东西啊”

    然后。这个问题，就这么愉快的攻克了。

学习也就是这么个过程吧。

 

三层之间的数据传递问题：

    沉浸大约一个星期的时间，满打满算我也就实现了三个界面。

開始之后，一直在研究三层之间数据的交换，期间传递过实体，用起来挺方便的。可是假设遇到非单一的数据之后，传递实体就出现故障了。之后開始传递dataTable，用起来要方便一些。

 

    总的来说。開始做系统之后，代码的阅读量……不提了。相比于第一次机房收费系统来说，难度的确添加了不少。相比于面向过程的程序来说。面向对象的程序更加好看。代码量的大小。不能决定一个程序的好坏。要想降低代码的反复。去满足单一职责原则就能够实现。

    对于还没有開始敲系统的时候。直接就设计出sqlHelper这样的事情。会丧失非常多。丧失学习的经历，出错的经验。

就拿上次学习的《大话设计模式》，为什么有那么多的人喜欢。那是由于每一个模式，都有一个背景故事。

所以在学习的时候。人们都能知道这个模式。为什么这么构造。

    不要想着走捷径，仅仅有真正体会到写程序的反复，你才干真正体会到设计者的用意。码农是不可缺少的一个阶段。