机房收费系统的重构已经開始非常久了，近期两天才感到有了一点儿头绪。


      对这次重构，刚開始计划的是先做数据库，然后优化下，列出每一个窗口对表的訪问关系，抽出经常使用的訪问作为存储过程，然后把訪问数据库的经常用法封装成SqlHelper.这部分就是数据库的部分。


     然后就是软件的结构：总体上是分了七层：三层+实体+外观+抽象工厂+D层接口。尽管计划的非常好，可是在详细分层这里想了非常久。


    最先是对D层開始下手的。D层是什么？是对表的訪问，将对数据库的读取和写入都封装成D层的类，那么，类又依照什么分呢？后来想了想曾经学习三层的时候做的7层的登陆窗口，那个时候，D层是依据表来的，将訪问每张表的方法总综合写成一个类。


     在纠结中，顺便进行着考试系统的測试，中间夹着这学习了非常多东西，感觉还是挺充实的，尤其是看了十几集的牛腩视频，给了我非常多启示。最终在一个周六，画了一天类图，让看到了自己纠结非常久的成果了：


    对于D层：基本是依照表来，将表抽象出一个类或者几个类，在每一个类里面，尽量让全部的方法去訪问表中同样的字段，也就是说，尽管D层主要依照表来，可是也用功能去辅助分类，比方，对于訪问两张表的情况，就将这种方法依据功能放在相似与他功能实现上有联系的类中。


   做完D层之后，向上到了接口层，才发现慘了，事实上我应该先做接口的。由于D层是用来实现接口层的，而不是接口层依据D层出现的。也就是说，编程要面向接口。唉，当时怎么就没想起来呢？


     接着做的是实体层，实体层是做什么的呢？先想想我们曾经程序中是怎样传递数据的：我们比方，我们注冊一个学生，这个学生可能写到学生信息表里面有十几条字段值要写进去，传递过程中在程序内部写这么多的值是非常easy丢掉一两个的，有了实体层，我们能够非常好的发挥封装的作用，将全部数据打包传递，就像给你寄个快递一样，不管多大还是多小，都给你打个包，不至于丢失什么东西。


   对于抽象工厂，延续抽象工厂+反射+配置文件的高大上的做法，返回接口，后来写代码的时候，发现修改起来果然很easy，当我修改D层的时候，上面的东西根本不用动。


   接着是B层，对于B层，它接收从U层过来的数据，向下送到D层进行处理，并将D层返回的数据放在这里进行推断和处理，并将结果返回给U层。可是它是怎样进行分类的，这个问题想了好久。看大家博客和当面交流，大家都大致是这样做的：1，依照U层窗口来；2，依照用例来；。。。。事实上我是比較看好依照用例来的，由于假设U层有非常多窗口的话，会造成B层类过多。可是依照用例来也是有问题的，假设我添加�功能，就要去修改类。好像怎么着都不完美。后来，想到设计模式上说的一句话：不论什么需求的变动都是须要成本的。我认为如今这个阶段我还是选择一种方法做下去比較好，假设实现的过程中，发现了更好的方法，能够再去修改。


    对于外观层，是对B层的进一步抽象，这次做到最后的时候，去掉了外观层，由于感觉这个系统太小了，B层的抽象程度已经相当高了，加了外观层就是冗余 了。


   这样，仅仅剩下最后的U层，它仅仅用来实现主要的输入输出就能够了。

   解耦完成~~~~