机房收费系统的重构已经开始很久了，最近两天才感到有了一点儿头绪。
对这次重构，刚开始计划的是先做数据库，然后优化下，列出每个窗体对表的访问关系，抽出常用的访问作为存储过程，然后把访问数据库的常用方法封装成SqlHelper.这部分就是数据库的部分。
然后就是软件的结构：整体上是分了七层：三层+实体+外观+抽象工厂+D层接口。虽然计划的很好，但是在具体分层这里想了很久。
最先是对D层开始下手的。D层是什么？是对表的访问，将对数据库的读取和写入都封装成D层的类，那么，类又按照什么分呢？后来想了想以前学习三层的时候做的7层的登陆窗体，那个时候，D层是根据表来的，将访问每张表的方法总综合写成一个类。
在纠结中，顺便进行着考试系统的测试，中间夹着这学习了很多东西，感觉还是挺充实的，尤其是看了十几集的牛腩视频，给了我很多启发。终于在一个周六，画了一天类图，让看到了自己纠结很久的成果了：
对于D层：基本是按照表来，将表抽象出一个类或者几个类，在每个类里面，尽量让所有的方法去访问表中相同的字段，也就是说，虽然D层主要按照表来，但是也用功能去辅助分类，比如，对于访问两张表的情况，就将这个方法根据功能放在相似与他功能实现上有联系的类中。
做完D层之后，向上到了接口层，才发现惨了，其实我应该先做接口的。因为D层是用来实现接口层的，而不是接口层根据D层出现的。也就是说，编程要面向接口。唉，当时怎么就没想起来呢？
接着做的是实体层，实体层是做什么的呢？先想想我们以前程序中是如何传递数据的：我们比如，我们注册一个学生，这个学生可能写到学生信息表里面有十几条字段值要写进去，传递过程中在程序内部写这么多的值是很容易丢掉一两个的，有了实体层，我们可以很好的发挥封装的作用，将所有数据打包传递，就像给你寄个快递一样，无论多大还是多小，都给你打个包，不至于丢失什么东西。
对于抽象工厂，延续抽象工厂+反射+配置文件的高大上的做法，返回接口，后来写代码的时候，发现改动起来果然非常容易，当我改动D层的时候，上面的东西根本不用动。
接着是B层，对于B层，它接收从U层过来的数据，向下送到D层进行处理，并将D层返回的数据放在这里进行判断和处理，并将结果返回给U层。但是它是如何进行分类的，这个问题想了好久。看大家博客和当面交流，大家都大致是这样做的：1，按照U层窗体来；2，按照用例来；。。。。其实我是比较看好按照用例来的，因为如果U层有很多窗体的话，会造成B层类过多。但是按照用例来也是有问题的，如果我增加功能，就要去修改类。好像怎么着都不完美。后来，想到设计模式上说的一句话：任何需求的变动都是需要成本的。我觉得现在这个阶段我还是选择一种方法做下去比较好，如果实现的过程中，发现了更好的方法，可以再去改动。
对于外观层，是对B层的进一步抽象，这次做到最后的时候，去掉了外观层，因为感觉这个系统太小了，B层的抽象程度已经相当高了，加了外观层就是冗余 了。
这样，只剩下最后的U层，它只用来实现基本的输入输出就可以了。
解耦完毕~~~~
