码迷,mamicode.com
首页 > Web开发 > 详细

与机房收费系统的再一次相处(.NET版):

时间:2014-07-26 15:17:00      阅读:255      评论:0      收藏:0      [点我收藏+]

标签:datagridview   style   使用   strong   文件   数据   io   问题   

        机房收费系统个人重构的尾巴,也就是到了整体总结的时候了。师傅的每一次验收都会有太多的收获,自己暴漏的漏洞也越多。

        首先,说说时间。有史以来,觉得最高效利用时间的一次,这和师傅的指导和督促是拖不了关系的。正直专业期末考试的那个月,时间抓起来就稍微有点费劲,但是,做好规划,还是觉得没有那么忙。因为在开始之前,师傅就给规定了时间,说什么内容多长时间内完成。每天都有自己的计划,要完成几个窗体或者是画多少图,早就找米老师谈过时间管理的问题,只有这时才深有体会。有这样的好师傅管着就好好学习,如果师傅不管了那岂不是又要回去。所以自己要养成自己管自己的习惯,提前做好计划。

        可能是每天都在赶着进度,完成该完成的内容,所以忽略了细节,当师傅第一次给看的时候就出现了很多细节的东西没有做。主要是:

      

        数据库的设计

1、E-R图:

        要严格按照E-R图的标准来画,注意实体之间的关系。

2、符合三范式

        也许你会认为胡杨版数据库有一些冗余,像是充值和退卡表既有学号又有卡号,如果是一个卡号的充值记录,就要重复的查出持有该卡的学号。我们完全可以去掉学号,当查询卡号的时候自然就标识了该卡的学号(除了一个学生有多张卡,我设计的是一个学生只持有一张卡)

3、注意主外键关系

        当关联的表删除数据时,我们要考虑的是不是破坏了这种关系,这时我们可以应用触发器或者存储过程。

4、存储过程天使还是魔鬼

        当涉及到复杂的SQL语句时,由于没有使用多触发器或是存储过程,因为新鲜又节省了麻烦,还解决了问题,这样提高了我们的效率。但是使用是不是有弊端呢?

        存储过程主要是对后期的维护增加了困难。当发现某个存储过程似乎错了,或者不满足新的业务需求,没有人敢修改他们,最好的办法是:再加一个新的。这样存储哦过程的数量越来越多,越来越难以命名——函数难命名不是编码的问题,而是涉及的问题。于是,在项目运行两年以后,还是难以形成一个优质稳定的业务开发平台,人们还在研究数据表、类型……

         说到这里,我们应该得出结论。存储过程是不好的。因为我们自己做的系统,等师傅验收之后就安静的放在自己的电脑里,没有人会再去理会它了。但是一些大的项目就不同,需要时时的维护,而且后期的维护会更加的重要。

         但是如果我们有这样的需求:数据库中有大量的实时运行数据,需要定期把这些数据进行简单的行列规整,放到另外一个数据库中做分析统计之用。在这种情况下我首选存储过程。存储过程应该是处理“数据”,而不要处理“业务”。并且极大的减少了IO消耗,真正的体现了它的效率优势。

      

       使用EAuml

1、总体框架(包图)比较重要

         这是理清这个系统的逻辑结构的第一步

2、三层的划分的标准和粒度

        有些人是按照功能分,有些人是按照表的划分。当然各有特色。

当你B层类的划分粒度太细的时候就会显得B层很臃肿,几乎是一个类一个功能,这样就没有了逻辑判断一说。但是划分粒度小的话,又会觉得B层划分功能不全。

3、外观模式是不是可有可无

          我一直知道为什么加外观模式,我也一直不知道为什么加外观模式。当一个界面用例比较多,需要实例化N个业务逻辑层,才能一一实现,那么不如就创建一个外观,将业务逻辑层的类进行整合。当U层只需要实例一个外观类,就能全部实现。但是一个才窗体如果只有一个功能,那么外观模式就真心多余了。还有就是外观层是不应该出现逻辑判断的,因为它毕竟不是逻辑层。

        所以外观层应该是在需要的时候有,没必要的时候无的(个人观点)

4、图的注释

        让师傅看图的时候,师傅说把注释都加上,我说我觉得都能看得懂吧。她说过几天你就看不懂了。于是我听话的把注释都加上。果然有的没有加注释的想起来是什么功能的时候是有些费劲的。有人说过好的代码注释会占到50%。看一个编程人员的水平就要先看他的注释。这是一种习惯,一种态度,一种为人民服务的思想。

      

         EA使用的技巧

          听了一个师哥的话才知道原来EA是如此的强大,我又是多么的渺小。EA可以导入VS代码,这些相信大家都知道,当然EA还是可以设计数据库直接导入的数据库的表,具体到一个字段等。接口的实现等,当我们没有尝试过的都觉得很强大,当时听完了就觉得自己对它的认识真是一知半解。

      

        系统本身

1、注重实现功能,忽略了细节

(1)、输入框提示名字,不能只是一个MsgBox

(2)、同一个用户不能同时登录系统值班

(3)、一些输入框的输入限制

(4)DataGridView表的一些注意事项

2、返回实体与返回DataTable

         简单的说下区别,返回DataTable自然是简单好理解的,但是这恰好违背的解耦的思想,三层之间通过DataTable来传递数据,前一层调用后一层的数据需要知道DataTable里面数据字段的名称。这样当一些牛人通过你的错误提示会嵌入到你的数据库中。这是很不安全的。返回实体就不一样了,三层之间通过实体通信,因为每一层只要知道实体的名字就可以了,不要知道具体的字段名称。当然返回泛型集合也可以直接和GridView直接绑定数据源。

3、一些自身控件的使用

        .net框架下有许多控件不需要安装,这样达到了很好的复用效果,应用平台也广泛起来。

4、注释的重要性

        包括头文件注释(可以预先定义)、代码段注释,特殊语句的注释等。第二次提到了注释,可见注释的重要性。这是让一个人读懂你代码的关键。


         没想到一口气总结了这么多,没有图没有真相,总之全是文字。当自己敲出了分层的系统时开始了面向对象的征程,还是会为自己鼓一次掌的。一个月的时间匆匆而过,可以说每一次的相处都会有太多的收获。编程仍在继续,即将迎来机房收费系统的合作版,期待中……

与机房收费系统的再一次相处(.NET版):,布布扣,bubuko.com

与机房收费系统的再一次相处(.NET版):

标签:datagridview   style   使用   strong   文件   数据   io   问题   

原文地址:http://blog.csdn.net/xdd19910505/article/details/38128761

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!