技术点滴

最近在研究项目中上线的测试框架和脚本。

同时新开的项目即将招新人成立项目组。所 以 老大让我准备下相关的资料
  没法。毕竟也还有点时间。自己也想REVIEW一下
  想起上一个公司曾经有一个通用的DAO接口框架（我们根据他调用底层的东西）来进行DAO处理
所以就开始看下关于DAO的框架（包括原理。相关开源的。以前接触过的）
  因为下一个项目主要是涉及数据库的操作。所以肯定会用到




PART1
  DAO设计模式也有缺点：
   优点就不用多说了。。。。
       
　　代码重复：从EmployeeDAOImpl清单可以清楚地看到，对于基于JDBC的传统数据库访问，代码重复（如上面的粗体字所示）是一个主要的问题。一遍又一遍地写着同样的代码，明显违反了基本的面向对象设计的代码重用原则。它将对项目成本、时间安排和工作产生明显的副面影响。

　　耦合：DAO代码与JDBC接口和核心collection耦合得非常紧密。从每个DAO类的导入声明的数量可以明显地看出这种耦合。

　　资源耗损：依据EmployeeDAOImpl类的设计，所有DAO方法必须释放对所获得的连接、声明、结果集等数据库资源的控制。这是危险的主张，因为一个编程新手可能很轻易漏掉那些约束。结果造成资源耗尽，导致系统停机。

　　错误处理：JDBC驱动程序通过抛出SQLException来报告所有的错误情况。SQLException是检查到的异常，所以开发人员被迫去处理它，即使不可能从这类导致代码混乱的大多数异常中恢复过来。而且，从SQLException对象获得的错误代码和消息特定于数据库厂商，所以不可能写出可移植的DAO错误发送代码。

　　脆弱的代码：在基于JDBC的DAO中，两个常用的任务是设置声明对象的绑定变量和使用结果集检索数据。假如SQL where子句中的列数目或者位置更改了，就不得不对代码执行更改、测试、重新部署这个严格的循环过程。

　　让我们看看如何能够减少这些问题并保留DAO的大多数优点。

　　进入Spring DAO