bean一样,该解决方案要求开发人员编写持久性代码。
与BMP bean不同的是,它还要求开发人员编写持久性逻辑。
因而。
开发人员负责确定何时将数据持久保留在数据存储中以及何时从数据存储装入数据。
3.Java数据对象是最新的持久性机制。
JDO提供了面向对象的持久数据存储。
开发人员使用POJO (无格式普通Java对象,plain ordinary Java object)来装入和存储持久数据。
1.3面向应用的持久层
设计1.3.1持久层概述 现今的应用系统设计中,MVC(Model.View.Contr01)作为主流系统架构模式之一,贯穿了整个设计流程。
MVC中的M,也就是所谓的Model,则可以说是与业务逻辑和数据逻辑关联最为紧密的部分。
而持久层作为Model层面中的主要组成部分,其设计的优劣势必对系统的整体表现产生至关重要的影响。
持久,英文即Persistence,也就是把数据保存到可掉电式存储设备中,以供之后使用。
大多数情况下,特别是对于企业级应用,数据持久化往往也就意味着将内存中的数据保存到磁盘上加以固化,而持久化的实现过程则大多通过各种关系型数据库来完成,本文主要围绕基于关系型数据库的数据持久化技术加以研究。
所谓“持久层”,就是在系统逻辑层面上,专注于实现数据持久化的一个相对独立的领域(Domain)。
对于麻用系统而言,数据持久功能大多是必不可少的组成部分.但是这并不意味着,在所有应用系统中已经具有了“持久层”的概念。
之所以要独立提出一个“持久层”的概念,而不是“持久模块”、“持久单元”,也就意味着我们的应用系统中.应该有一个相对独立的逻辑层面,专注于数据持久化逻辑的实现,与系统其他部分相对而言,这个层面应该拥有一个较为清晰和严格的逻辑边界,通常情况下可通过一个简单的逻辑图表达(图1,2)。
3 东南大学硕士学位论文 图1-2持久层逻辑边界 上面的框图最大的特色就是其各部分之间的清晰划分,这也就是所谓“层”存在的意义。
持久层代表某个特定系统中的一个逻辑层次,这个层次将数据使用者和数据实体相关联。
通过这样一个中问层次,实现了高效、清晰的专业分工和职责划分。
1.3.2持久层设计模式 实际的业务系统很可能非常错综复杂,如果不采用适当的代码分离技术,对于一个动辄包含了十几个甚至几十个业务步骤的业务过程而言,混杂的业务逻辑和数据访问代码会极大地干扰程序员的阅读,必定为日后的维护带来极大的凼难。
为了解决这个
问题,我们可以引用DAO(DataAccess ObjecO模式。
DAO模式实际上是两个模式的综合,即DataAccessor模式和ActiveDomainObject模式的组合。
其中DataAccessor模式实现了数据访问和业务逻辑的分离,而Active Domain Object模式实现了业务逻辑的对象化封装,一般我们将这两个模式组合使用。
DAO模式通过对业务层提供数据数据抽象层接口,可以实现以下四个目标: 1.数据存储逻辑的分离 通过对数据访问逻辑进行抽象,为上层结构提供抽象化的数据访问接口。
业务层无需关心具体的select,insert,u州ate操作,这样一方面避免了业务代码中混杂JDBC调用语句,使业务逻辑实现更加清晰,另一方面.由于数据访问接口与数据访问实现相分离,也使得开发人员的专业划分成为可能。
某些精通数据库操作技术的开发人员可以根据接口提供数据库访问的最优化实现,而精通业务的开发人员则可以抛开数据层的繁琐细节,专注于业务逻辑编码。
图1-3为DAO模式的实现层次。
4 第一章绪论 图1-3 DAO模式的实现层次 2. 数据访问底层实现的分离 DAO模式通过将数据访问划分为抽象层和实现层.从而分离了数据使用和数据访问的底层实现细节。
这意味着业务层与数据访问的底层实现细节无关,也就是说,我们可以在保持上层结构不变的情况下,通过切换底层实现来修改数据访问的具体机制。
3. 资源管理和调度的分离 在数据库操作中,资源的管理和调度是一个非常值得关注的主题。
大多数系统的性能瓶颈往往并非集中于业务逻辑处理本身。
在系统涉及的各种资源调度过程中,往往存在着最大的性能黑洞,而数据库作为业务系统中晟重要的系统资源,自然也成为关注的焦点。
DAO模式将数据访问逻辑从业务逻辑中脱离开米,使得在数据访问层实现统一的资源调度成为可能,通过数据库连接池以及各种缓存机制的配合使用,往往可以在保持上层系统不变的情况F,大幅度提升系统性能。
4.数据抽象 在直接基于JDBC调用的代码中,程序员面对的数据往往是原始的RecordSet数据集,虽然这样的数据集可以提供足够的信息,但对于业务逻辑开发过程而言,如此琐碎和缺乏寓意的字段型数据实在令人厌倦。
DAO模式通过对底