在JAVA 编程的时候, 有时候看起来非常直接的实现却非要用设计模式转若干个弯去实现他, 这似乎显的很多余,但是采用一些成熟的设计模式,会使程序更加的健壮,松耦合以及好维护和扩展. DAO 设计模式 背景： 根据数据源的不同，访问数据的方法也会有所不同，访问持久化的数据源，比如数据库，也会由于其存储类型的不同（关系数据库，面向对象的数据库，简单文件储存，其他方式）和提供商自定义数据类型的不同而有很大的区别。 出现的问题: 许多投入使用的,J2EE W EB 应用程序在一些时候需要进行数据的持久化. 对于很多的W EB 应用,数据的持久化存储可以通过不同的机制来实现,文档中清楚的标出了这些用于访问不同数据持久机制的API的不同之处. 还有一些其他的应用或许会访问一些位于特有系统上的数据资源.比如,在大型机的系统之上,也可能在轻量级的目录访问协议 LDAP 仓库中,或者是其他什么系统. 还有就是,数据也可能是由诸如B2B这样的外部集成系统服务,信用卡局服务,或者其他服务来提供的.一般来说,程序使用一些共享的分布式组件来表示持久化数据.比如实体BEAN. 当一个程序中实体 BEAN以比较直接的方式访问持久化数据时大多会考虑采用BEAN 管理持久化方式(BMP)说明白点,就是程序中的实体BEAN 包含有直接访问持久化数据的代码.另外一种情况,程序可以采用容器管理持久化,你不需要写任何代码,而是让容器自己来处理数据持久化的具体细节. 程序可以使用JDBC API 来访问位于关系数据库中的数据. 他使得在诸如关系型数据库这样的持久化载体中,对数据进行标准的访问和处理成为可能. 也使 J2EE 应用程序可以使用SQL 语句作为标准的访问关系型数据库语句. 然而,即便是都是关系型数据库的环境下,由于不同的数据库产品,也会导致 SQL 在使用上,语法和格式也各不相同. 对于不同类型的数据持久化仓库 ,差异甚至会更大. 访问机制,API,以及一些其他特性,会因为他们是关系型数据库,面向对象型数据库还是一般的文件而大相径庭.需要访问以前遗留下来的系统或者诸如大型主机,B2B 这样的专业系统中数据库的应用程序，会经常使用到一些自己特有的API. 这些特有的数据源对应用程序的编写提出了很大的挑战,而且很有可能在编写的过程中造成程序代码和数据访问代码间产生相互依赖性.当商业组件诸如：实体BEAN,会话 BEAN,以及serv lets 和 JSP 帮助对象这样的表示组件需要访问数据资源的时候,可以用标准的API 来实现其数据库的连接和数...
