与机房收费系统的再一次相处（.NET版）：

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

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

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

      

        数据库的设计

1、E-R图：

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

2、符合三范式

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

3、注意主外键关系

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

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

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

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

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

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

      

       使用EA画uml图

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、注释的重要性

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

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