很多的J2EE应用程序需要使用持久性数据(数据库、文件等)。不同的程序，持久性存储是各不相同的，并且用来访问这些不同的持久性存储机制的API也有很大的不同。假如应用程序要在不同的持久性存储间迁移，这些访问特定持久存储层的代码将面临重写。
　　
　　 !-- frame contents -- !-- /frame contents -- 　　如何解决这个问题？且看"DAO模式"
　　
　　数据访问对象(Data Acess Object) 模式
　　
　　一.环境
　　
　　根据数据源不同，数据访问也不同。根据存储的类型(关系数据库、面向对象数据库、文件等等)和供给商实现不同，持久性存储(比如数据库)的访问差别也很大。
　　　
　　二.问题
　　
　　许多真是的J2EE应用程序需要在一定程度上使用持久性数据。对于许多应用程序，持久性存储是使用不同的机制实现的,并且用来访问这些不同的持久性存储机制的API也有很大的不同。
　　
　　比如，应用程序使用实体bean(这里应该是指BMP的bean，CMP的bean已大大降低了与RDBMS的耦合)的分布式组件来表示持久性数据，或者使用JDBC API来访问驻留在某关系数据库治理系统(RDBMS)中的数据，这些组件中包含连接性性和数据访问代码会引入这些组件与数据源实现之间的紧密耦合。组件中这类代码依靠性使应用程序从某种数据源迁移到其他种类的数据源将变得非常麻烦和困难。当数据源变化时，组件也需要改变，以便于能够处理新类型的数据源。
　　
　　(举个例子来说，我们UPTEL系统是使用JDBC API对 Oracle数据库进行连接和数据访问的，这些JDBC API与SQL语句散布在系统中，当我们需要将UPTEL迁移到其他RDBMS时，比如曾经迁移到INFORMIX，就面临重写数据库连接和访问数据的模块。)
　　
　　三.作用力
　　
　　1.诸如bean治理的实体bean、会话bean、servlet等组件往往需要从持久性存储数据源中检索数据，以及进行数据存储等操作。
　　
　　2.根据产品供给商的不同，持久性存储API差别也很大，这些API和其能力同样根据存储的类型不同也有差别，这样存在以下缺点，即访问这些独立系统的API很不统一。
　　
　　3.组件需要透明于实际的持久性存储或者数据源实现，以便于提供到不同供给商产品、不同存储类型和不同数据源类型的更轻易的移植性。
　　四.解决方案
　　
　　使用数据访问对象(DAO)模式来抽象和封装所有对数据源的访问。DAO治理着与数据源的连接以便检索和存储数据。
　　
　　 !-- frame contents -- !-- /frame contents -- 　　DAO实现了用来操作数据源的访问机制。数据源可以时RDBMS,LDAP,File等。依靠于DAO的业务组件为其客户端使用DAO提供更简单的接口。DAO完全向客户端隐藏了数据源实现细节。由于当低层数据源实现变化时，DAO向客户端提供的接口不会变化，所有该模式答应DAO调整到不同的存储模式，而不会影响其客户端或者业务组件。重要的是,DAO充当组件和数据源之间的适配器。
　　
　　(按照这个理论，假如我们UPTEL系统使用了DAO模式,就可以无缝的从ORACLE迁移到任何一个RDBMS了。梦想总是很完美的，且看看DAO模式如何实现)
　　
　　1.结构，图1是表示DAO模式中各种关系的类图。
　　
　　此主题相关图片如下：
　　
　　iframe src="/uploadImages/2007-5-2/20075212414841207.jpg" frameBorder=0 width=590 scrolling=yes height=349>/iframe
　　(图片较大，请拉动滚动条观看)
　　
　　2.参与者和职责
　　
　　1)BusinessObject(业务对象)
　　
　　代表数据客户端。正是该对象需要访问数据源以获取和存储数据。
　　
　　2)DataAccessObject(数据访问对象)
　　
　　是该模式的主要对象。DataAccessObject抽取该BusinessObject的低层数据访问实现，以保证对数据源的透明访问。BusinessObject也可以把数据加载和存储操作委托给DataAccessObject。
　　
　　3)DataSource(数据源)
　　
　　代表数据源实现。数据源可以是各RDBMSR数据库，OODBMS,XML文件等等。
　　
　　4)valueObject(值对象)
　　
　　代表用做数据携带着的值对象。DataAccessObject可以使用值对象来把数据返回给客户端。
　　
　　DataAccessObject也许会接受来自于客户端的数据，其中这些用于更新数据源的数据存放于值对象中来传递。
　　
　　3.策略
　　
　　1).自动DAO代码产生策略
　　
　　因为每个BusinessObject对应于一个非凡的DAO,因此有可能建立BusinessObject,DAO和低层实现(比如RDBMS中的表)之间的关系(映射)。一点这些关系(映射)已经建立，我们就可以编写与应用程序有馆的代码生成的简单工具了(什么？自己写GP程序？用ORM的附带工具自动生成不就完了，最多自己写几个Adapter,牛人就是不同，啥都要自己写...)，其中的工具可以产生该应用程序需要的所有DAO代码。
　　
　　假如DAO需求很复杂，我们可以采用第三方工具，其中这些工具提供对象到RDBMS数据库的关系映射(这里指的是前面提到的ORM工具，全称是Object Relation Mapping,目前成熟的ORM工具有很多:Hibernate,OJB,Torque,TopLink等等)。
　　
　　这些工具通常包含GUI工具来把业务对象映射到持久性存储对象，并且因而定义中间DAO。一旦这些映射完成，这些工具会自动地生成代码，并且也许会提供其他增值功能，比如结果缓冲、查询缓冲、与应用程序集成，以及与其他第三方产品(比如分布式缓冲)地继续，等等。
　　
　　（增值服务：Torque提供了结果缓冲,Hibernate提供了对Oracle数据库SQL指令的优化,OJB提供JDO API、OMDB API）
　　
　　2).数据访问对象的工厂策略
　　
　　通过调整抽象工厂和工厂方法模式，DAO模式可以达到很高的灵活度。
　　
　　当低层存储不会随着实现变化而变化时，该策略可以使用工厂方法模式来实现该策略。以产生应用程序需要的大量DAO。图2是这种情况下的类图。
　　
　　此主题相关图片如下：
　　
　　
　　
　　当低层存储随着实现变化而变化时，该策略可以使用抽象工厂方法模式而实现。
　　
　　图3是这种情况下的类图。
　　
　　此主题相关图片如下：
　　
　　iframe src="/uploadImages/2007-5-2/20075212414948895.jpg" frameBorder=0 width=590 scrolling=yes height=400>/iframe
　　(图片较大，请拉动滚动条观看)
　　5.结果
　　
　　1).启用透明性
　　
　　业务对象可以是使用数据源，而无须了解该数据源实现的具体细节。访问是透明的，原因是实现被隐藏在DAO的内部。
　　　
　　2).启用更轻易的迁移