寒假将近四十天,主要的学习工作就是重构机房收费系统。从一开始的茫然无措,到现在的肤浅认知。下面是我重构中主要的三版图:
版本一
版本二
版本三
无论是画图,还是在编码阶段,感觉我都花费了很多的时间。设计时,感觉画图遇到的困难很大。开始想的就很跑偏,所以画的图找晞晓勇师哥审核了好几次。做完了他给我的一个登录例子,我又在网上找了几个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数据库等一连串的课程,也都需要进一步的进行研究、学习。
学习没有尽头,继续向前。