搜索

Java模式设计之数据访问对象模式

gecimao 发表于 2019-06-07 02:49 | 查看: | 回复:

  很多的J2EE应用程序需要使用持久性数据(数据库文件等)。不同的程序,持久性存储是各不相同的,并且用来访问这些不同的持久性存储机制的API也有很大的不同。如果应用程序要在不同的持久性存储间迁移,这些访问特定持久存储层的代码将面临重写。

  根据数据源不同,数据访问也不同。根据存储的类型(关系数据库、面向对象数据库、文件等等)和供应商实现不同,持久性存储(比如数据库)的访问差别也很大。

  许多线EE应用程序需要在一定程度上使用持久性数据。对于许多应用程序,持久性存储是使用不同的机制实现的,并且用来访问这些不同的持久性存储机制的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管理着与数据源的连接以便检索和存储数据。

  DAO实现了用来操作数据源的访问机制。数据源可以时RDBMS,LDAP,File等。依赖于DAO的业务组件为其客户端使用DAO提供更简单的接口。DAO完全向客户端隐藏了数据源实现细节。由于当低层数据源实现变化时,DAO向客户端提供的接口不会变化,所有该模式允许DAO调整到不同的存储模式,而不会影响其客户端或者业务组件。重要的是,DAO充当组件和数据源之间的适配器。

  (按照这个理论,如果我们UPTEL系统使用了DAO模式,就可以无缝的从ORACLE迁移到任何一个RDBMS了。梦想总是很完美的,且看看DAO模式如何实现)

  代表数据源实现。数据源可以是各RDBMSR数据库,OODBMS,XML文件等等。

  代表用做数据携带着的值对象。DataAccessObject可以使用值对象来把数据返回给客户端。

  DataAccessObject也许会接受来自于客户端的数据,其中这些用于更新数据源的数据存放于值对象中来传递。

  因为每个BusinessObject对应于一个特殊的DAO,因此有可能建立BusinessObject,DAO和低层实现(比如RDBMS中的表)之间的关系(映射)。一点这些关系(映射)已经建立,我们就可以编写与应用程序有馆的代码生成的简单工具了(什么?自己写GP程序?用ORM的附带工具自动生成不就完了,最多自己写几个Adapter,牛人就是不同,啥都要自己写...),其中的工具可以产生该应用程序需要的所有DAO代码。

  这些工具通常包含GUI工具来把业务对象映射到持久性存储对象,并且因而定义中间DAO。一旦这些映射完成,这些工具会自动地生成代码,并且也许会提供其他增值功能,比如结果缓冲、查询缓冲、与应用程序集成,以及与其他第三方产品(比如分布式缓冲)地继承,等等。

  当低层存储不会随着实现变化而变化时,该策略可以使用工厂方法模式来实现该策略。以产生应用程序需要的大量DAO。图2是这种情况下的类图。

  业务对象可以是使用数据源,而无须了解该数据源实现的具体细节。访问是透明的,原因是实现被隐藏在DAO的内部。

  DAO层使应用程序更加容易地迁移到一个不同的数据库实现。业务对象不了解低层数据实现。因而,该迁移只涉及对DAO层的变化。更进一步说,如果使用工厂策略,则有可能为每一个低层存储实现提供一个具体工厂实现。在这种情况下,迁移到不同的迁移实现意味着给应用程序提供一个新的工厂实现。

  由于DAO管理所有的数据访问复杂性,它可以简化业务对象和其他使用DAO的客户端中的代码。所有与实现有关的代码(比如sql语句)都被包含在DAO中,而不是包含在业务对象中。这样做提高了代码的可读性,已经代码生产效率。

  因为所有的数据访问操作现在被委托给DAO,所有单独的数据访问层可以被看作把数据访问实现与应用程序中的其他代码相隔离的。这种集中化使应用程序更容易地维护和管理。

  由于EJB容器用容器管理的持久性(CMP)来管理实体bean,该容器会自动地服务所有的持久性存储访问。使用容器管理的实体bean的应用程序不需要DAO层,因为该应用程序服务器透明地提供该功能。然而,当需要组合使用CMP和BMP时,DAO仍旧有用处。

  DAO会在数据客户端和数据源之间创建其他的对象层,其中该数据源需要被设计和实现以便于权衡该模式的好处。但是选择本方法也会带来额外的开销。

  在使用工厂策略时,我们需要设计和实现具体工厂的层次,以及这些工厂产生的具体产品层次。如果能够确保这种灵活性,则有必要考虑这种额外的工作。这样做会增加设计的复杂性。然而,在实现该工厂策略时,你可以首先考虑工厂方法模式,然后再根据需要过渡到抽象工厂。

本文链接:http://robynlynne.com/duixiangshi/451.html
随机为您推荐歌词
推荐文章

联系我们 | 关于我们 | 网友投稿 | 版权声明 | 广告服务 | 站点统计 | 网站地图

版权声明:本站资源均来自互联网,如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

Copyright @ 2012-2013 织梦猫 版权所有  Powered by Dedecms 5.7
渝ICP备10013703号  

回顶部