围的数据源内部的变动,组件也必须加以修改才能适应新的要求.无法平滑迁移。
在一般的项目中,这个缺点并不明显,但是在一些关键性的.大型的,具有历史连贯性的企业应用中,它们对于此类高可维护性,高可移植性的非功能需求尤其苛刻,上述缺点就显得至关重要了。
I.I.2论文研究内容和意义 为了避免陷入上述困境之中,在当今的大中型企业应用中,一般采用的策略就是将数据访问及其操纵的逻辑封装在一个相对独立的层次中。
这样,在持久化存储实现机制和应用
系统其余部分之间就产生了一道新的逻辑层次,通过这种分解的架构手段f21,解除了二者之间所存在的紧密耦合,同时也降低和限制了由于底层结构的变化而导致的上层修改,使得系统便于开发,维护和移植。
这个层次一般称之为数据持久层(Data Persister Layer)【3】,在有的场合中也称之为数据访问层(Data Access Layer),相对于实现业务逻辑的业务类和业务对象而言,实现数据持久功能的类和对象称之为数据访问类(也简称为数据类)和数据访问对象(也简称为数据对象).如图l-2所示: 如图I-I中的数据 I数据库访问层, 库访问者 I 即Client l 数据持久层,用 I数据库访问层 于负责数据库相 关的逻辑 持久化存储介质,如RDBMS,文件系统等持久层设计模式在增值服务网站系统的研究与应用 第1章综述 图1.2加入持久层后的系统架构 通过分离的数据持久层,我们可以在应用层次上,将应用逻辑与数据逻辑相分离。
对于一个业务系统而言,系统研发的日标在于为特定业务提供价值,这些特定的业务逻辑往往是系统实现的重中之重。
此时将核心之外的数据访问逻辑从开发人员的主要关注点剥离出去,有助于将精力更好地放在项目最有价值的地方,从而提高了开发效率【1】。
此外在资源层次上,可以将逻辑结构和物理结构相分离。
这里所谓的物理结构并非传统意义上的硬件设备,而是指我们无法控制的系统层面,比如底层数据库的接口,外部系统提供的服务等等。
如果条件允许,我们都应当利用合理的抽象设计将其和我们的系统隔离开来,将这些细节的变动与我们的业务逻辑相隔离。
这样做的目标只有一个,就是竭力使得当底层实现发生变动时,尽量避免对上层结构产生影响【1】。
综上所述,我们可以得到以下结沦:无论是理论上,还是实践中,如何构造一个优秀而实用的数据持久层都将是一个值得深入探讨的课题。
本人在2006年7月至2006年11月参与了一个彩信网站项目,该网站采用B/S架构,使用J2EE框架来开发。
本论文意在研究业界使用的优秀的持久层设计模式,根据该系统自身的架构特点,对该网站系统进行重构.使其具有良好的可扩展性和可维护性。
1.2持久层设计模式1.2.i设计模式背景 模式在现实生活中随处可见,它是成功经验的总结和复用。
模式思想起初形成于建筑学,Alexander对于模式的定义为:在某种经常重现的背景下,对某种特定问题的解决方法〔4】。
这里,Alexander给出了模式的三大要桑【5】: (1)背景(context) 那些适台应用该模式的可重现情形. (2)问题(problem) 出现在背景中的一系列影响力,即日标和约束。
(3)解决方案(solution) 4持九屉
设计模式在增值服务网站系统的研究与应用 第1章综述 可用于解决问题的经典设计形式或设计规财。
模式的基本特性有: (1)模式可以解决实际问题 模式能够解决一个特定的具体问题,而不是抽象的原则和策略。
(2)模式是经受过考验的概念 模式有实际解决问题的记录,而不只是理论上的思索和推导。
(3)模式中的解决方案不是显而易见的 某些求解技术(如设计风范和方法)根据原则直接推导出问题解,但模 式问接地产生问题解一对复杂
问题必须采用这种方法。
(4)模式表达了一种关系 模式不仅描述了模块,而且描述了更深层的系统结构和机制。
(5)模式具有很强的人文因素 最佳模式通常具有鏖好的美感兼兼容性。
模式有不l司的领域,建筑领域有建筑模式,软件设计领域也有设计模式。
模式也不断地