J2EE之DAO设计模式.doc

J2EE之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将数据源的实现细节对客户端完全的隐藏了起来. 因为,暴露给客户端的DAO接口在 低层数据源的实现发生改变时并不会随着改变,所以这种设计模式使得DAO可以适应不同的数据储存方式类型而不影响客户端和商业组件.最主要 的, DAO还在组件和数据源之间扮演着协调者的角色.以下是DAO设计模式中各个模块的解释： 1 BusinessObject指的是数据客户端,他通常需要去访问数据源以获得数据或储存数据.一个BusinessObject