机房收费重构——关于面向对象和分层的纠结
2014-05-25 15:12
225 查看
机房收费系统的重构已经开始很久了,最近两天才感到有了一点儿头绪。
对这次重构,刚开始计划的是先做数据库,然后优化下,列出每个窗体对表的访问关系,抽出常用的访问作为存储过程,然后把访问数据库的常用方法封装成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层,它只用来实现基本的输入输出就可以了。
解耦完毕~~~~
对这次重构,刚开始计划的是先做数据库,然后优化下,列出每个窗体对表的访问关系,抽出常用的访问作为存储过程,然后把访问数据库的常用方法封装成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层,它只用来实现基本的输入输出就可以了。
解耦完毕~~~~
相关文章推荐
- 机房收费重构——关于面向对象和分层的纠结
- 机房收费重构——关于面向对象和分层的纠结
- 重构机房----面向对象初步设想
- 机房收费重构——关于上下机的再思考
- 机房收费系统个人重构关于SQLHelper
- 的房费重构——纠结于面向对象和层次
- 从ATM机到机房收费中 我理解的面向对象
- 项目手记 (一) 重构机房收费系统--关于架构的第一次认识
- 重构版机房收费系统之分层、接口、数据库连接、反射+工厂(vb.net)
- VB.net版机房个人重构中组合查询的面向对象
- 机房收费重构——关于上下机的再思考
- 机房收费系统个人重构关于SQLHelper
- 关于面向对象和面象过程的一些感想
- 关于面向对象和面象过程的一些感想
- 重构机房收费系统(一)
- 机房收费系统——对象集合的使用
- jQuery版坦克游戏,缺陷面向对象重构版!
- 关于php面向对象动态绑定和静态绑定的理解
- 面向对象的优缺点(关于缺点部分,希望大家补充,个人实力实在不够,无法提出更深层次的缺点)
- 关于面向对象和面向过程的程序设计思想的思考和理解