.NET机房收费系统总结
寒假将近四十天，主要的学习工作就是重构机房收费系统。从一开始的茫然无措，到现在的肤浅认知。下面是我重构中主要的三版图：
版本一
版本二
版本三
无论是画图，还是在编码阶段，感觉我都花费了很多的时间。设计时，感觉画图遇到的困难很大。开始想的就很跑偏，所以画的图找晞晓勇师哥审核了好几次。做完了他给我的一个登录例子，我又在网上找了几个C#小例子，感觉实现起来都大同小异。接下来，进入了编码阶段。
开始编码的时候，还是一边写代码，一遍修正图。可是到了后面图的修改量太大了。改到恶心的地步，就一心编码了。图都是后补的。
这次重构最大的感慨就是：“在困难中成长”，经常遇到不懂的问题，成功的话一研究就是小半天；如果搞不懂这一天就下去了。等串下来，感觉所遇到的不应该有那么困难。
写函数方面收获
尽管本次重构中，有些地方的函数写的还不是非常好，但是我感觉这个寒假，我提炼函数的水平是飞速提升的。无论怎么说，之前还是习惯于把功能放在窗体下去写去实现。等发现冗余的时候，往往懒得去提炼出一个方法，而是采取粘贴复制的方式解决。
重构中，我尝到了提炼函数的好处。极大程度的减少了程序的冗余的同时，也减免了程序的出错率，代码开起来也整齐多了。
数据库操作方面收获
经历了前后两次重构，对数据库的增删改查有了全新的认知。频繁使用Insert，Delete，Update，Select，同时运行到Select查询语句中的内链接与外连接查询。在四个组合查询中我提炼了一个存储过程，四个查询共用一个存储过程，查询时，只需要将参数及其表的名字传入即可。具体实现大家可以参照我的这篇博客http://blog.csdn.net/liu765023051/article/details/7224411。
同时，我也遇到一个这样的问题。就是在编码的时候，发现数据的数据类型设计不是非常合理。查询写入数据要进行数据的转化，这是如果去改动数据库的话就会牵一发而动全身。其实我们根本没有必要去改动数据库，只需用convert函数转换一下数据类型即可。
架构方面的困惑
在架构方面，有一点是肯定的，一个DAL层肯定对应一个表的增删改查，返回相应的DataTable或者Boolean类型。UI层的逻辑也比较清晰，只是用来接受用户的请求，并调用BLL层对此做出反应，再呈献给用户。
而BLL层的设计就众说纷纭了。如果一个BLL层是与DAL层的增删改查对应的，这样BLL的负担就会相对减小。而把主要的逻辑放在的外观层，经由外观去协调UI与DAL层的关系。我感觉这样设计BLL的作用就微乎其微了，它根本就没有处理复杂的业务逻辑；另一种想法，将BLL层与UI层对应，而BLL层本身就充当外观的作用，一次性调用多个DAL层，来完成UI层的功能。我感觉着用想法，也非常合理。只不过如果是比机房收费系统大很多的项目，这样处理的话，BLL层的任务就太庞大了。
所以，个人感觉这次重构采用哪种方式都可以，也可以都试试。对于以后的或大或小的项目，应该因地制宜，按情况而定吧。
设计模式的运用
对于设计模式，感觉很多都加的无关紧要，以至于到了后面有去掉了。DAL层加的抽象工厂加反射是必须的，上面架构方面谈到的外观模式，由于采用多文档窗体，如果在窗体显示时，你非要实例化一下再显示，也可以加一个单例模式（具体情况，可以参照大话设计模式中单例模式给的实例，它里面就是实例化窗体之后，再显示），最后还有在算法这块儿加策略模式。下面是我策略模式的类图
编码命名
关于编码的命名，我感觉我的是很乱的。之前只是参看了程序员编程标准，没有看提高班命名手册，所以开始的时候有些一塌糊涂，有些地方如果不看备注的话，我自己都搞不懂是干什么的。鉴于此，我打算再写一篇关于命名规范的博客，尽请期待。。。
不可忘记的错误
刚开始做系统的时候，我曾经改过解决方案的名字。结果弄得一塌糊涂，系统到处出问题，这里调好了，那里又出了许多莫名的错误。后来跟勇哥谈起此事，他讲了个例子给我。命名空间名就好比咱们学校的名字，学校的名字是不能乱改的，改动后就会出很多问题，而学校内部却可以随便命名，没人管你。
总结
关于包图的建模，我尝试着单纯的使用抽象工厂模式，就是上面的版本二。因为之初我认为抽象工厂加反射根本就是简单工厂的升级版，如果仅仅是加一个简单工厂还不如加去加一个抽象工厂来的实惠。可是勇哥还是说运用抽象工厂加反射才是正道。用过之后，才发现反射这里原来也很有讲究，UI层是需要引用DAL层，每次编译，都会重新编译DAL层。而DAL层生成的dll也会被复制到UI层相应的文件夹。
关于三层，我还需要进一步的学习去夯实；软工、UML、设计模式、SQL数据库等一连串的课程，也都需要进一步的进行研究、学习。
学习没有尽头，继续向前。
