机房重构---我们“重构”出了什么？

           机房重构马上就要结束了，在这“第三个”系统结束的时候，有必要思考一下我们重构的目的了。

          也许有人说，还有什么目的呀，不就是编程语言换成了.Net，做出来，调完bug,能运行就得了呗。这么浮夸的日子里，还叫什么劲啊？

          对于有这种想法的人，我必须道一声：您（白）辛苦了 ！

          无论做什么事，没有一点总结性思考是无法进步的。

          我下面的一些重构论述或者说反思性总结也存在许多不足，希望大家多多指正，在此先致谢！

          本文将从五个方面论述一下这次的重构系统，分别是系统架构、UML图指导、设计模式应用、数据处理和面向对象。

 

          首先，系统架构方面。

          在这次重构中，我们都运用了三层架构，目的是降低耦合，提高系统的重用性和可维护性等各种目的。在设计中，和第一次机房的基本面向过程编程相比，我们确实也深刻的体会到了有架构的方便和易维护。

          通过添加外观、SqlHelper、配置文件等基本辅助模块或工具，我们再次体会到了独立的封装给我们带来的巨大便利，从解耦到封装，就看到了面向对象。

 

          其次，UML图和文档的指导。这次重点是放在了UML图上，用例图、包图、类图和时序图是关键。

          包与”三层“、类图与三层中D层和B层的设计（不同的分类标准，如按数据库表还是功能进行B层设计）、时序图对功能执行过程的指导等都是密不可分，需要我们必须提前仔细分析的。当然，这些都是建立在需求分析和用例设计之上的。

 

          再次，设计模式方面。

          现在为止，应用设计模式的难点在于如何将系统的某个功能或系列功能对应到设计模式中。学习过程中，能够对各个实例理解和形象化描述出来是重点，这样我们才能更好的对应到以后的系统实例分析中。

          在机房重构中，目前我了解或使用的设计模式应用有：

          策略模式-对于不同类型的用户实行不同的计费方法

          抽象工厂+反射-对不同的表进行简单化切换

          外观-在U层和B之间的外观层，进一步解耦，使U层更具独立性

          模板-类似的窗体不需要一遍遍重复的代码

          适配器-外部报表和vb.net融合

          单例-保证一个窗体不被各种new出来

          职责链-从一般用户到操作员再到管理员，总有一个要解决问题

 

          再谈谈数据处理方面。

          数据处理无论什么时候都是一个重点需要解决的问题，尤其是在现代大数据时代，效率和安全显得更为重要。在这次机房重构中，对数据库一些功能有了更为深入的理解。          

          这里说两点。一是在通过第一次做机房的时候对建数据库的生涩、缺乏必要三范式分析的基础上进行了第二次数据库建立和改良。即使在系统编程过程中，有时候还是避免不了去动数据库，改改字段，以弥补我们分析的不足和临时的灵光一现。

          二是当我们一而再，再而三的路过标有“事务、存储过程、触发器、视图”等等关键词的路牌时，有必要驻足去探查一番了。存储过程和触发器执行方便切更符合封装性特点，事务对系统某些”互相影响“功能的严格控制等特点让我们不得不去探索它们的优点，进而应用。存储过程的应用如上下机、组合查询等；事务可以考虑用于充值、结账方面。

 

          最后，谈一下系统与面向对象。

          在这次重构中，体会到了面向对象无处不在的思想优点。

          比如继承性：管理员对操作员的继承，操作员对一般用户的继承，不仅明确了他们之间的联系，还简化了结构。另外接口的应用也是继承。

          封装性就体现的更多了，数据封装、功能封装无处不在。一个良好的系统设计需要对面向对象、面向接口有着极为深入的理解，另外，在实际操作过程中进行实践更是提升我们理解的最佳手段。

 

          总结：对于此次机房重构，还有很多实践上应用的不足，如何把这些思考通过这次重构，乃至结合下次的合作版实现，才是对经验最好的补充。这样在应对下面的学习时，就可以把学习本身作为一个系统进行完美解析和最佳实践了。