【机房重构】——上下机之思考过程

做上下机的时候,刚开始没有头绪的。总觉得下机好麻烦,还要有好多计算。后来有一个小想法,想在界面动态显示消费时间,于是下面的思考就出现了。

原思路:

以上就是我最初的思路,知道要用策略模式,但是不知道怎么去写啊,怎么办?先把功能实现了再说策略模式吧!

当与同学交流后发现,我的所有更新都是在下机之后更新的。这样做会出现两种问题:

1、程序故障以及断电故障:会出现数据丢失更新问题;

2、当查询上机记录或上机状态的时候,消费时间以及消费金额,余额等是没有发生变化的,不能及时查询上机动态。

这就是延迟更新所遇到的问题,那我们就让它及时更新呗,所以思路二诞生了!

修改后的思路:

思路一遇到的问题是消费时间,消费金额以及余额会出现丢失更新的情况。

因为在上机的时候,消费时间就开始每隔一分钟更新一次了,那消费金额,余额也可以实时更新啊!所以我们可以在上机的时候,就将这些信息写入数据库。这样查询记录的时候就可以实时看到此卡的上机动态。然后下机的时候直接更新下机时间以及下机日期即可。

上下机过程中遇到的问题:

对于上下机的管理,全部在一张表T_LineInfo中,下面我分析一下这样做的利弊:

利:全部强制下机方便。只需将所有表的下机日期以及下机时间,上机状态统一更新为当前日期时间,以及“强制下机”。不需要循环下机,因为余额已经计算完毕。

弊:正常下机麻烦。因为下机的时候要修改上机状态,所以不能将上机状态作为表的查询条件。因而我想到了用卡号以及上机时间作为查询条件。在vb.net中的Datatime取出来的时间值是连日期一起包括的,时间转换上就会麻烦一些。

查询上机状态时间要长一些。

机房也快要结束了,没有必要去改表了,就先这样吧,等合作的时候在权衡利弊去设计表吧!

总结:

到现在机房快要做完了,我才发现我的B层全写错了,逻辑方面理解错了,B层抽象错了,那我的F层也好不到哪去,同时又增加了U层的代码负担。也快完工了,就不改了,这是一个过程吧,没有错,哪有对。在磕磕绊绊中也过来了,只能这样安慰自己了。不过现在有一个自认为比较清晰的思路,下一步合作应该怎样去改!就这样在不断修改中成长!

时间: 2024-11-06 11:32:34

【机房重构】——上下机之思考过程的相关文章

机房收费重构——关于上下机的再思考

有句话叫做no zuo no die,我大概就是这种人吧.why?做机房收费系统的时候,按照一般方法也能实现,但这次做上下机的时候,总感觉这么做对自己来说,没什么提高,然后就停下来,重新想想上下机还能怎么做? 后来,大致采用的思路是这样的:将上下机的读写数据的过程写成两个存储过程,负责读取和更改数据.中间的计算过程写在代码里面:中间判断时间的过程用职责链模式来实现,判断一般用户还是临时用户用策略模式实现.这样,整个上下机的过程就是这样的: 1,用上机的存储过程使学生上机,然后将学生上机信息写入表

机房收费系统上下机之观察者模式的尝试

如果读者想在本篇文章中看到观察者模式的巧妙应用,大概有些不可能了.因为这里我只是想把自己的一种思路展现给大家,然后和大家探讨. 背景: 在敲机房收费系统的过程中,都是别人说可能会用到什么模式,然后自己针对这些模式进行思考,然后去模仿书中的例子去用. 这不,师姐说上下机这里能用观察者模式,然后我就琢磨了一番,只是收获不是很丰硕,貌似也和师姐讲课中的设想不一样. 我在琢磨使用观察者模式时,已经把系统中和上下机有关的功能实现了.只是在写代码的过程中发现,每次下机,都需要先把正在上机的卡的上机信息查出来

【机房重构】一步一步往上爬——七层中的那些事

机房重构开始已经一个多星期了,从最开始的理解登录到现在已经成功完成至少一次的"增"."删"."改"."查"的操作,现在在七层的这个大环境下,从最开始的奄奄一息,终于变得生龙活虎起来了. 之前总是听师哥师姐们说,敲完登录一条线了,后面就会很顺利了.可是,从我来说,事实并非如此.然而,磕磕绊绊,四个字足以形容我的这些天.不过,我心态好,我可以忍受一个人花时间调代码的孤独,再说,我也可以找小伙伴.找师父帮助我,我有什么理由不成功.

职责链模式应用——下机(机房重构知识点总结)

下机涉及两个方面,消费时间和消费金额. 对消费时间的处理用的是职责链模式,感觉这个模式用的非常妙,參考的师哥的博客:<机房收费下机中用到的策略与职责链解析>:消费金额的处理用策略模式.针对不同的用户类型. 这里着重介绍职责链的应用. 依据需求,将时间分为三个阶段,准备时间:不收取费用:至少上机时间:大于准备时间,小于至少上机时间的,一律按至少上机时间算.单位递增时间:大于至少上机时间后.按单位递增时间累加. TimeHandler类,定义一个处理请示的接口 Public MustInherit

机房收费系统VB版(四)——上下机

在敲系统的过程中,觉得有点困难的是上下机和结账.当理不清关系,没有头绪的时候,我们先画画图吧,把逻辑理清了,思路自然就有了,不会的再去查就可以了.今天我们就先来分析一下所谓的上下机. 一.上机     上机流程图:     解释说明:    (1)判断文本框的内容是否为空,是否为数字,"否"则弹出提示框: (2)若文本框为数字,判断卡号是否注册,"否"则弹出提示框: (3)若卡号已经注册, 判断卡号是否正在上机,"是"则弹出提示框: (4)若卡号

史上最简洁的向上取整(机房重构知识点总结)

在机房收费系统的基本数据设定中,有一个单位递增时间,这就需要我们满足如下需求: 假如递增单位时间是5,那么需要实现如下的效果: 5-->5 6-->10 7-->10 11-->15 我们一步一步来,先看一个简单的例子: 2.0-->2 2.1-->3 2.4-->3 2.6-->3 我开始用的取整,然后加1,结果带有小数的可以达到目的,但这会让2.0变为3,怎么办呢?abs(int(-x)),先转换为负数,取整后再变为正数即可.因为int(),会让一个浮点

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

机房重构立即就要结束了,在这"第三个"系统结束的时候,有必要思考一下我们重构的目的了. 或许有人说,还有什么目的呀,不就是编程语言换成了.Net,做出来,调完bug,能执行就得了呗.这么浮夸的日子里,还叫什么劲啊? 对于有这样的想法的人,我必须道一声:您(白)辛苦了 ! 不管做什么事,没有一点总结性思考是无法进步的. 我以下的一些重构论述或者说反思性总结也存在很多不足,希望大家多多指正,在此先致谢! 本文将从五个方面论述一下这次的重构系统,各自是系统架构.UML图指导.设计模式应用.数

机房重构时利用状态模式实现消费时间的计算

在做机房重构时,我们会在学生上下机计算学生上机时间时,会出现消费时间随着基本数据设定表中的数据变化而变化,这里不仅仅是数据的变化,还包括不同时间段内消费时间具体确定问题.主要分为三个时间段的计算 1.准备时间:即在此时间段内,消费金额为0 2.至少上机时间:如果上机时间超过了准备时间,但是少于至少上机时间,那么此时消费时间为至少上机时间 3.按正常消费时间来算:此时,消费时间大于至少上机时间后,则按照正常时间来算 通过对业务的分析,我们发现在不同时间段,最终的消费时间的计算方式是不一样的.如果我

机房重构总结之步履蹒跚

一.惨淡的回忆 1.艰难的开始 记得我很早就开始机房重构了,好像是在六月份,当时正好赶上考试,它就自然搁浅了.当暑假开始后,搬到了五楼学英语,虽然每天晚上都能干自己的事情,但是心里总是对它有点抵触,所以一直迟迟不肯下手,只是小打小闹,学着画图,分析着功能,重新设计了一下数据库,而实际上却总想去看自考书或者三级网络的书,总之,能逃就逃.最后,实在是不能再拖了,硬着头皮上吧.时间再抓紧点,自己在用心一点,开始了前期的画图.设计等工作. 2.平淡的过程 整个过程只能用平淡来形容.由于是在不知道该怎么画