初步认识JAVA+DAO设计模式讲述.docVIP

最近参与WEB编程项目,采用STRUTS框架,在处理到数据持久化的时候决定采用DAO设计模式,因此读了SUN的J2EE 核心设计模式中DAO设计模式,现翻译为中文于大家共享，不足与错误指出望大家指出,也愿该文对大家有所帮助.在JAVA编程的时候, 有时候看起来非常直接的实现却非要用设计模式转若干个弯去实现他, 这似乎显的很多余,但是采用一些成熟的设计模式,会使程序更加的健壮,松耦合以及好维护和扩展. ????????????????????????????? DAO 设计模式背景：根据数据源的不同，访问数据的方法也会有所不同，访问持久化的数据源，比如数据库，也会由于其存储类型的不同（关系数据库，面向对象的数据库，简单文件储存，其他方式）和提供商自定义数据类型的不同而有很大的区别。出现的问题:许多投入使用的,J2EE WEB 应用程序在一些时候需要进行数据的持久化. 对于很多的WEB应用,数据的持久化存储可以通过不同的机制来实现,文档中清楚的标出了这些用于访问不同数据持久机制的API的不同之处. 还有一些其他的应用或许会访问一些位于特有系统上的数据资源.比如,在大型机的系统之上,也可能在轻量级的目录访问协议LDAP仓库中,或者是其他什么系统. 还有就是,数据也可能是由诸如B2B这样的外部集成系统服务,信用卡局服务,或者其他服务来提供的.一般来说,程序使用一些共享的分布式组件来表示持久化数据.比如实体BEAN. 当一个程序中实体BEAN以比较直接的方式访问持久化数据时大多会考虑采用BEAN管理持久化方式(BMP)说明白点,就是程序中的实体BEAN包含有直接访问持久化数据的代码.另外一种情况,程序可以采用容器管理持久化,你不需要写任何代码,而是让容器自己来处理数据持久化的具体细节.程序可以使用JDBC API 来访问位于关系数据库中的数据. 他使得在诸如关系型数据库这样的持久化载体中,对数据进行标准的访问和处理成为可能. 也使J2EE应用程序可以使用SQL语句作为标准的访问关系型数据库语句. 然而,即便是都是关系型数据库的环境下,由于不同的数据库产品,也会导致SQL在使用上,语法和格式也各不相同.对于不同类型的数据持久化仓库,差异甚至会更大. 访问机制,API,以及一些其他特性,会因为他们是关系型数据库,面向对象型数据库还是一般的文件而大相径庭.需要访问以前遗留下来的系统或者诸如大型主机,B2B这样的专业系统中数据库的应用程序，会经常使用到一些自己特有的API. 这些特有的数据源对应用程序的编写提出了很大的挑战,而且很有可能在编写的过程中造成程序代码和数据访问代码间产生相互依赖性.当商业组件诸如：实体BEAN,会话 BEAN,以及servlets和JSP帮助对象这样的表示组件需要访问数据资源的时候,可以用标准的API来实现其数据库的连接和数据的具体操作.但是,如果把连接数据库和数据的操作代码和这些组件写在一起的话，会导致这些组件和数据库操作之间的耦合,这种耦合的存在,使得在应用程序中从当前数据源类型迁移到另一种数据源类型变的十分困难和乏味. 如果数据源改变了,那么你的组件也不得不改变来适应新的数据源.必要性:1 像 bean管理实体bean, 会话 bean, servlets, 以及其他一些像jsp帮手对象这样的组件，通常需要从持久化的数据库或者原先遗留下来的系统以及 B2B， LDAP这样的系统中提取或存储数据。2 用于持久化储存的API因他们的提供商的不同而各自不同。还有一些的数据源也可能有自己的一些特有的API或者是一些非标准的API。众多类型的数据持久化系统和载体，比如： 关系型数据库，面向对象数据库管理系统，XML文档，简单文件等等，使得API各不相同和性能各异。我们缺乏一种统一的API来对以上的不同的系统或者文件载体进行操作。3 组件通常使用特有的API从内部系统或者是遗留下来的系统来访问或是提取数据。4 当某些特定的访问机制和API包含在这些组件中的时候，将直接影响他们的兼容性。5 组件需要对现有的持久化储存系统或者数据源的实现足够透明，以便在向不同的产品，不同类型的储存系统，和不同类型数据源中进行迁移的时候，变的简单。解决方案使用数据访问对象来抽象和封装对数据源的所有访问。数据访问对象负责管理与数据源的连接，来获取和储存其中的数据。数据访问对象实现与数据源相关的访问机制。 数据源可以是关系型数据库管理系统，可以是像B2B EXCHANGE这样的内部服务，可以是LDAP库，或者也可以是通过CORBA IIOP 或者是低层sockets来访问的商业服务. 依赖于DAO的商业组件只对他的客户端暴露一些非常简单的DAO外部接口. DAO将数据源的实现细节对客户端完