机房重构--验收小结

盼望着，盼望着，春天的脚步快没了，看到这整张图，整个人都不好了。自考，等级考试过后，发现重构确实拖了太长时间。有必要来反思一下。

一.相比之前多学到了什么？

1.首先是在用设计模式中，深刻理解了“高内聚，低耦合”，如何在设计模式中解耦，优化代码的维护和更改，减少代码的更改。

2.对代码的封装，正则表达式，sqlhelper，存储过程，触发器，都是一个个的封装，减少代码的重复。

3.对于传参又用到了实体，用到了泛型。

4.还有就是在外观层对B层方法的封装。

二.新的认识

（一）.存储过程，触发器，视图到底哪个更好？

  （1） 存储过程（Stored Procedure）是一组为了完成特定功能的SQL 语句集，相当于我们的SQL语句。

优点：

①重复使用。存储过程可以重复使用，从而可以减少数据库开发人员的工作量。
②提高性能。存储过程在创建的时候在进行了编译，将来使用的时候不再重新翻译。一般的SQL语句每执行一次就需要编译一次，所以使用存储过程提高了效率。
③减少网络流量。存储过程位于服务器上，调用的时候只需要传递存储过程的名称以及参数就可以了，因此降低了网络传输的数据量。
④安全性。参数化的存储过程可以防止SQL注入式攻击，而且可以将Grant、Deny以及Revoke权限应用于存储过程。
简单讲：
1.存储过程只在创造时进行编译，以后每次执行存储过程都不需再重新编译，而一般SQL语句每执行一次就编译一次,所以使用存储过程可提高数据库执行速度。
2.当对数据库进行复杂操作时(如对多个表进行Update,Insert,Query,Delete时)，可将此复杂操作用存储过程封装起来与数据库提供的事务处理结合一起使用。
3.存储过程可以重复使用,可减少数据库开发人员的工作量
4.安全性高,可设定只有某些用户才具有对指定存储过程的使用权
缺点：
1：调试麻烦，但是用 PL/SQL Developer 调试很方便！弥补这个缺点。
2：移植问题，数据库端代码当然是与数据库相关的。但是如果是做工程型项目，基本不存在移植问题。
3：重新编译问题，因为后端代码是运行前编译的，如果带有引用关系的对象发生改变时，受影响的存储过程、包将需要重新编译（不过也可以设置成运行时刻自动编译）。
4： 如果在一个程序系统中大量的使用存储过程，到程序交付使用的时候随着用户需求的增加会导致数据结构的变化，接着就是系统的相关问题了，最后如果用户想维护该系统可以说是很难很难、而且代价是空前的，维护起来更麻烦。

（2）触发器

触发器是一个特殊的存储过程。是一个能事件出发再有由系统自动执行对数据库修改的语句。

作用：触发器可通过数据库中的相关表实现级联更改，不过，通过级联引用完整性约束可以更有效地执行这些更改。触发器可以强制用比CHECK约束定义的约束更为复杂的约束。与 CHECK 约束不同，触发器可以引用其它表中的列。一个表中的多个同类触发器（INSERT、UPDATE 或 DELETE）允许采取多个不同的对策以响应同一个修改语句。

 慎用：触发器本身没有过错，但滥用的话，将会造成数据库及应用程序的维护困难。如果我们对触发器过分的依赖，势必影响数据库的结构，同时增加了维护的复杂程度。、

（3）视图

视图是从若干基本表或其他视图构造出来的表，是一张虚拟的表，其内容由查询定义。同真实的表一样，
视图包含一系列带有名称的列和行数据。但是视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。

 视图的优点:
  1.视图着重于特定数据。
      视图可以让用户或者程序开发人员只看到他们所需要的数据，而不需要把表中的所有信息与字段暴露出来，这样增强了数据的安全性。
  2.简化数据的操作，易维护。
      我们可以将经常用到的多表联合查询出来的数据，或特定的结果集定义为视图，这样就起到了模块化数据的作用。我们在使用这些数据时直接查询该视图就可以，而不用到处写长长的SQL语句，这样也起到易维护的作用。
  3.视图可以限定查询数据。
      比如：对于不同的用户，我们只提供部分数据给他。这样，我们就可以在视图中限定结果集，然后返回该视图给他。这样，无论用户怎么对视图定义查询条件，他也不能查询出我们不想提供给他的数据。

因为视图其实就是一段SQL语句，所以它的结果都是每次调用时动态生成的。如果不合理的定义视图，必然带来性能上的损耗。
下面是我们在创建视图应该要注意的几点：
    1. 操作视图会比直接操作基础表要慢，所以我们尽量避免在大型表上创建视图。
    2. 尽量不要创建嵌套视图，就是在视图中使用视图。这样在查询时，会多次重复访问基础表，带来性能损耗。
    3. 尽量在视图只返回所需的信息，尽量不要在视图使用不需要访问的表。  
    4. 频繁使用的视图，可以使用索引视图来代替。

总的来说：在大型表或者复杂定义的视图，可以首选存储过程。并且听师傅说道，在我们做的项目中，用到存储工程缓解系统访问压力。

（二）传datatable和传泛型哪个好？

（1）DataTable：是弱类型，没有办法直接看出数据表中字段的数据类型，List<>是强类型。最大的区别是，List<>可以灵活转换，不用装箱和拆箱，这个过程中可能会造成数据的错误丢失，所以DataTabel也不是很安全的。

（2）泛型集合：把DataTable中的每一行记录视为一个实体类，把其中的字段读取出来，存放到实体类的属性中，再把所有的实体类存在泛型集合中。因此，DataTable中有多少个记录，泛型集合中就有多少个实体类，每个实体类的属性和DataTable的字段是相对应的。

优点：

减少输入，传输时只需要传一个实例T就可以获取它的任何属性。
正确地构建的泛型类可以真正减少代码中的安全性问题。
使用泛型类还可以提高性能。其中最大的一个改进是.NET框架组件不会在值类型上使用包装（boxing）。尽管泛型类可以使用多个数据类型工作，但是它在后台单独地处理每一种数据类型。这种技术确保了在你的工作量最小的情况下，应用程序提供最佳的性能。
但是，在绑定数据时也会产生一些麻烦，数据库类型，要与实体类型对应正确才可。

所以，为了安全性，和层与层间的低耦合，我们提倡泛型集合。

（三）减少代码又增加的代码

当相同一段代码出现三次以上时，我们就要考虑了，比如输入框的限制，数字，字符，日期，一连串if语句是不行的，就要将他们封装起来。这样减少后期维护带来的困难。

设计模式中，一条原则就是尽量增加代码，不要修改代码，设计模式，就解决了这个问题。那么当我们的需求有变化时，就可以不破坏结构，进行维护。一些有价值代码的添加是很有意义的。

三

总结：师傅说，重要的不是设计模式的使用，而是要明白为什么要用这个？这样用？好处是什么.在合作中，重要的不是把功能实现，而是为什么要加这个东西，你新学到了什么？这次又对文档和UML图有了新的认识，知道了他们的重要性。接下来就是去实践了....