（计算机应用技术专业论文）基于aopioc技术的数据验证组件的研究与实现.pdf

中文摘要 摘要 几乎所有与用户进行交互的应用项目都会用到数据验证。通常情况下，开发 人员会采用o o p ( 面向对象编程) 技术完成数据验证的操作。但是由于数据验证 操作的实现是分散在多个模块中的，如用户注册模块、登录模块、查询模块等都 会需要相关的数据验证操作，随着软件开发规模的不断扩大化且越来越复杂，采 用o o p 技术不能很好的解决数据验证问题。 a o p ( 面向切面编程) 作为o o p 的一种补充和完善，使开发人员可以将数据 验证等影响多个类的操作封装到一个可重用的模块中，从而可消除o o p 引起的代 码混乱和代码分散问题，增强了系统的可维护性和代码的重用性。同时，与a o p 互相辅助的i o c 模式，作为面向构件技术【8 i 【1 3 】的一种体现，可将原来纠缠在一起 的构件模块分割成多个相对独立的类，并通过配置文件来实现类或模块之间的关 联，降低了软件系统各个模块之间的耦合性。 本文对利用a o p f l o c 技术改进数据验证操作进行了有益的探索和实践，主要做 了以下工作l 1 分析了o o p 和a o p 的区别和联系，指出了o o p 在解决数据验证等操作中存 在的不足，并研究了如何利用a o p 技术来解决这些问题。 2 对i o c 模式做了分析与研究，其重点是研究如何利用i o c 模式来实现数据验证 逻辑与其它业务逻辑间的松散耦合。 3 基于对a o 胁c 的研究，设计并实现了一个服务器端数据验证功能组件 a l l 4 v a l i d a t c 。该组件可以帮助开发人员利用a o p i o c 的方式解决软件项目开 发过程中普遍存在的数据验证代码分散和代码混乱的问题。 文中最后测试了该组件并将其应用到实际项目中。测试结果证明了采用 a l l 4 v a l i d 砒e 组件进行j 2 e 咖b 项目中的数据验证，可显著的减少代码编写量， 并可解决代码重复和代码混乱等问题。可极大的提高软件开发效率，降低开发成 本，具有一定的实用价值。 关键词： 0 p ( 面向切面编程) ；l o g ( 依赖注入模式) ； 1 1 4 v a ii d a t e 服务器端数 据验证 英文摘要 d a t av a l i d a t i o nc o m p o n e n tb a s e do na o p i o c a b s t r a c t a l m o s ta l la p p l i c a t i o np r o j e c t sw h i c hw e r ei n t e r a c t e dw i t hu s e r sn e e dd a t a v a l i d a t i o nf u n c t i o n u n d e rn o r m a lc i r c u m s t a n c e s ，p r o g r a m m e r sw o u l du s eo o p t e c h n i q u e s t os o l v ed a t av a l i d a t i o n o p e r a t i o n h o w e v e r , b e c a u s ed a t a v a l i d a t i o n o p e r a t i o ni si nd i f f e r e n tm o d u l e s ，s u c ha su s e rr e g i s t r a t i o nm o d u l e s ，t h ee n t r ym o d u l e ， q u e r ym o d u l ea n do t h e rr e l e v a n t w i t ht h ec o n s t a n te x p a n s i o no ft h es c a l eo fs o f t w a r e d e v e l o p m e n t ，o o pt e c h n o l o g yc a nn o ts o l v et h ep r o b l e mo f d a t av a l i d a t i o nw e l l a o p t e c h n o l o g yc a nb es e e na ss u p p l e m e n ta n dp e r f e c tt oo o p p r o g r a m e r sc a n p a c k a g eo p e r a t i o n se f f e c t e dd i f f e r e n tc l a s ss u c ha sd a t ev a l i d a t i o ni n t os o m er e u s a b l e m o d u l e e l i m i n a t e st h ec o n f u s i o na n df r a g m e n t e dc o d ed u r i n gc a u s e db yo o pm e t h o d d e v e l o p m e n t e n h a n c e dc o d er e u s a b i l i t ya n dm a i n t a i n a b i l i t yo ft h es y s t e m m e a n w h i l e ， i o ca sa o p ss u p p o r tm o d e l ，a sar e f l e c t i o no fc o m p o n e n t o r i e n t e dt e c h n o l o g y ， e n t a n g l i n go r i g i n a lc o m p o n e n t sb es e p a r a t e di n t or e l a t i v e l yi n d e p e n d e n to ft h em o d u l e s a n dr e a l i z ei n t e r a c t i o n sb yx m lf l i e st or e d u c et h ec o u p l i n gb e t w e e nm o d u l e s t h i sa r t i c l eu p 掣a d c dd a t av a l i d a t i o no p e r a t i o nb a s e do na o p f l o ct e c h n i c a l ，a n d c a r r i e so nt h eb e n e f i c i a le x p l o r a t i o na n dt h ep r a c t i c e ，m a i n l yr e s e a r c h i n gw e r eb e l o w ： 1 a n a l y z e dt h ed i f f e r e n c ea n dr e l a t i o nb e t w e e no o p a n dt h ea o p p o i n t e do u t o o p si n s u f f i c i e n c yi no p e r a t i o no nd a t av a l i d a t i o no p e r a t i o n s ，a n dr e s e a r c h e dh o wt o s o l v et h e s ep r o b l e m su s i n ga o p t e c h n o l o g y 2 m a d et h ea n a l y s i sa n dr e s e a r c h i n go ni o cp a t t e r n , m a i n l ys t u d i e sr e a l i z e s l o o s i n gt h ed a t ac o n f i r m a t i o nl o g i cw i t ho t h e rs e r v i c el o g i cu s i n g t h ei o c p a t t e r n 3 d e s i g n e da n dr e a l i z e ds e r v e r - e n dd a t av a l i d a t i o nf u n c t i o nm o d u l ea l l 4 v a l i d a t e b a s e do nt h er e s e a r c ht oa o p ，1 0 c t h i sm o d u l em a yh e l pt h ep r o g r a m e r st os o l v ed a t ev a l i d a t i o n eo p e r a t i o n si nt h e w a yo fu s i n ga o p i o ci np r e v a l e n ts o f t w a r ed e v e l o p m e n tp r o c e s s a v o i dv e r i f yt h e c o d ea n dt h ec o d es c a t t e r e dp r o b l e m s i nt h ee n do ft h i sa r t i c l e ，t e s tw i l lb ea p p l i e dt oa n a c t u a lp r o j e c t t e s tr e s u l t sd e m o 璐t r a t e dt h a tt h eu s i n go fa l l 4 v a l i d a t ec o m p o n e n tf o r t h ej 2 e e e j bp r o g r a m m n i gc a ns i g n i f i c a n t l yr e d u c et h ea m o u n to fd u p l i c a t i o no fc o d e a n dt h ec o d ec a na d d r e s ss u c hi s s u e s s o f t w a r ed e v e l o p m e n tc a ng r e a t l yt a k ei m p r o v e e f f i c i e n c ya n dl o w e rc o s t i th a ss o m ep r a c t i c a lv a l u e i np r o j c o tp r o g r a mp r o c e s s 英文摘要 k e yw o r d s ：a o p ；i o c ；s e r v e rv a l i d a t i o n ；a l l 4 v a l i d a t e 大连海事大学学位论文原创性声明和使用授权说明 原创性声明 本人郑重声明：本论文是在导师的指导下，独立进行研究工作所取得的成果， 撰写成硕士学位论文：基王q i 煎撞苤的数握坠适组仕曲盟究皇塞丑：。除 论文中已经注明引用的内容外，对论文的研究做出重要贡献的个人和集体，均已 在文中以明确方式标明。本论文中不包含任何未加明确注明的其他个人或集体已 经公开发表或未公开发表的成果。 本声明的法律责任由本人承担。 论文作者签名：崔蔚劾嗥砷年弓月堙日 学位论文版权使用授权书 本学位论文作者及指导教师完全了解“大连海事大学研究生学位论文提交、 版权使用管理办法”，同意大连海事大学保留并向国家有关部门或机构送交学位 论文的复印件和电子版，允许论文被查阅和借阅。本人授权大连海事大学可以将 本学位论文的全部或部分内容编入有关数据库进行检索，也可采用影印、缩印或 扫描等复制手段保存和汇编学位论文。 不保密赢青在以上方框内打“”) 论文作者躲能气蒜蔫茏于日期：白肘。年；月己目 基于a o p i o c 技术的数据验证组件的研究与实现 1 1 研究的背景与意义 第1 章绪论 现在大多数j 2 e e 项目都会选择o o p 的开发方式。但在实践中开发人员逐渐 认识到，o o p 对软件职责的划分是“垂直的”，即每一棵继承树负责软件系统中 一个特定部分的功能【1 1 。但是，在实际问题中，常常有一些“水平”的功能需求， 这些“水平”的功能需求都有一个共同的特点，那就是它们的操作对象横跨了多 稞继承树。并且操作本身对于操作对象来说是透明的。因此，o o p 经常表现出一 些不能自然的适合单个程序模块或者几个紧密相关的程序模块的行为。如数据验 证、日志记录、事务完整性、授权、安全及性能优化等问题1 2 1 。本文中将这种行为 称为“横切关注点”，因为它们跨越了o o p 编程模型中的典型职责界限。由于“横 切关注点”行为的实现是分散多个程序模块中的，如果使用o o p 技术来解决“横 切关注点”行为的会产生以下两大类问题。 ( 1 ) 代码混乱 在整个软件系统中，业务功能被称为“纵向关注点”，数据验证、日志记录、 出错处理等辅助实现“纵向关注点”的配套设施被称为“横切关注点”。一个“纵 向关注点”的实现需要一个或多个“横切关注点”的辅助，在以“纵向关注点” 的角度来分析和设计应用系统的时候，用当前的o o p 进行开发就会导致在一个实 现“纵向关注点”的程序模块中要包含实现多个“横切关注点”的代码，这个程 序模块就会变成一个为不同目的而编写的指令的混合体。这样会导致整个程序模 块结构不清晰，实现“纵向关注点”和“横切关注点”的代码之间存在很高的依 赖性，增加了程序出错的机会。 ( 2 ) 代码分散 一个“横切关注点”会辅助一个或多个“纵向关注点”的实现。比如在某个 应用系统中需要进行数据验证，实现数据验证的方法会散布存在于多个动作类文 件中。利用o o p 技术来解决这种需求，最直接的办法就是创建一个基类( 或接口) ， 将数据验证的功能放在其中，并让所有需要数据验证功能的类继承这个基类( 或接 口) 1 2 1 。但是如果这个需求是软件开发后期提出的，那么需要修改的地方就会分散 第1 章绪论 在多个动作类文件中。这样大的修改量无疑会增加出错的几率，并且加大系统维 护的难度。 针对数据验证问题，程序设计者们曾提出了一些相应的解决方案，如单根继 承体系和某些结构型设计模式【3 l 等，但都不能从根本上解决闯题。 采用a o p 技术和l o c 模式相结合的开发方式则可以很好的解决这类问题，利 用a o p 将“横切关注点”从“纵向关注点”中分离出来，然后各自独立的实现这 些关注点。形成相应的功能组件。最后利用i o c 模式将实现“纵向关注点”和“横 切关注点”的操作代码按照具体需求重新组织到一起，并通过配置文件来控制它 们之间的相互依赖关系。 以a o p i o c 组合的方式进行项目开发能够在不影响或少影响实际应用程序代 码的情况下通过配置文件来重新建立关联，可显著的减少代码编写量，并可解决 代码重复和代码混乱等问题。 1 2 国内外研究现状 x e r o xp a l oa l t or e s e a r c hl a b ( p a r c ) 的研究人员在1 9 9 0 年开始对面向对象 思想的局限性进行分析和研究，并提出了一种全新的面向切面的编程思想，这一 思想的主旨是通过减少不同模块中的相同代码来帮助开发人员提高工作效率【射。就 在f a r c 对面向切面编程进行研究的同时，美国n o r t h e a s t e r n u n i v e r s i t y 的c r i s t i n a l o p e s 博士和其同事也开始了类似的思考。美国国防先进技术研究计划署( d e f e n s e a d v a n c e dr e s e a r c hp r o j e c t sa g e n c y 即d a r p a ) 也注意到了这项工作，并提供了科 研经费，鼓励将二者的工作成果结合起来，由此产生了a o p 技术【5 1 a v a n a d e 公 司的高级方案构架师a d a mm a g e e 认为，a o p 的核心思想就是”将应用程序中的商 业逻辑同对其提供支持的通用服务进行分离【6 】。 j 2 e e 编程正在变得越来越复杂。j 2 e e 已经发展为一个由a p i ( 通用编程接口) 、 大量的代码和复杂的配置组成的庞大系统。为了解决这种庞杂性，新的框架和方 法不断的涌现，其中包括a p a c h ea v a l o n 项目创始人s t e f a n om a z z o c c h i 和m a r t i n f o w l e r 提出了i o c 模式。利用i o c 模式可以将类之间的关系通过第三方( 如配置 文件) 进行注射，不需要类自己去解决调用关系【。”。这样就避免了整个系统的各个 模块之间互相调用的混乱局面。 2 基于a o p i o c 技术的数据验证组件的研究与实现 在国外基于a o p i o c 技术为核心的软件产品非常丰富，其中包括著名的 s p d n g 、p i c o c o n t a i n e r 、h i v e m i n d 等开源框架，借助于a o p a o c 的技术优势，这 些产品都可以为开发人员提供一种相对于e j b 来说轻量高效的开发环境1 8 】。 在国内基于a o p i o c 技术的软件产品却很少，其中只有j d o n f r a m c w o r k 和 n a n n i n g ( 南宁) 是两个相对成熟的产品。但是这两种框架产品在具体的项目中应 用的范围并不广泛。目前大多数需要用到a o p i o c 模式进行开发的项目多数会采 用s p r i n g 框架进行辅助开发。本文将基于a o p 技术和l o c 模式相结合的开发方式， 具体设计和实现一个基于服务器端数据验证组件，并将其以低侵入的方式融入到 现有j 2 e e e j b 开发过程的组件产品中，为主流的j 2 e e e j b 项目开发提供数据验 证功能的解决方案。 1 3 本文的内容组织 第一章 第二章 第三章 第四章 第五章 第六章 介绍了课题的研究背景，研究内容及意义： 简要介绍了本文所要用到的技术及关键概念，为论文做好理论基础； 分析了现有的数据验证技术以及解决方案的优势和不足，为本文观点的 提出做好了铺垫： 在深入分析与研究a o p i o c 技术的基础上，设计并实现了一个基于服务器 端的数据验证组件- - a l l 4 v a l i d a t e ： 应用了这个组件并对其进行了实验评测； 总结与展望。 第2 章a o p 技术与l o c 模式概述 第2 章a o p 技术与i o c 模式概述 a o p 技术和i o c 模式( 反转控制，又叫依赖注入) 是一对互相支持和依赖 的组合开发方式。它们通过模块化方式来解决企业应用程序开发中普遍存在的“横 切关注点”问题。比如在典型的o o p 开发中，可能要将数据验证语句放在所有方 法和j a v a 类中才能实现数据验证功能，而采用a o p i o c 进行开发则可以利用 a o p 技术将数据验证服务进行模块化，然后通过i o c 模式用配置文件将它们应用 到需要数据验证功能的组件上。这样做的优势就在于j a v a 类不需要知道数据验证 服务的存在，也不需要考虑相关的代码实现。所以，基于a o p i o c 编写的应用程 序代码是松散耦合的。 2 1a o p 技术 2 1 1a o p 概述 a o p 是o o p 的一种补充和完善，同时也是g o f 设计模式的延续，设计模式 主要是为了解决调用者和被调用者之间解耦的问题，a o p 正是实现这种目标的手 段之一。它是一种体现分散关注思想的编程方法，它将开发人员的注意力集中在 了业务逻辑的切面中【9 1 。 所谓分散关注【1 0 1 就是将通用需求功能从不相关的类之中分离出来形成一个模 块。同时，还要能够使很多类共享这个通用需求功能，一旦通用需求功能发生变 化，可以不必修改很多类而只要修改这个通用需求功能模块。 在这里有个例子说明什么是面向切面编程中所谓的切面( a s p e c t ) 假设在一 个应用系统中。有一个共享的数据必须被并发的访问。首先，将这个数据封装在 数据对象中，称为d a t ac l a s s ，同时，有多个访问类，专门用于在同一时刻访问这 个数据对象f 1 1 l 。 为了完成上述并发访问的功能，必需要引入逻辑锁l o c k 的概念，也就是说， 某个时刻，当有一个访问类正在访问这个数据对象时，这个数据对象必须被上锁 l o c k e d ，用完后就立即解锁u n l o c k e d ，再供其它访问类进行访问。 基于传统的o o p 开发习惯，开发人员会创建一个抽象类，使所有的访问类都 继承这个抽象父类，如代码2 1 所示。 4 基于a o p i o c 技术的数据验证组件的研究与实现 代码2 1 抽象类w o r k e r 采用这种方式编写代码的不足之处在于抽象类w o r k e r 的a c c e s s d a t a o b j e c t ( ) 方法需要有“锁”操作的相关代码。但是由于j a v a 语言只提供了单继承，具体的 访问类只能继承这个父类，如果具体访问类同时还要继承其它父类将无法实现。 可见，具体访问类因为自身包含了“锁”操作的相关代码，只能被重用在相关有 “锁”动作的场合，重用范围很窄。 仔细研究这个应用中“锁”操作的功能，它其实有下列特性： ( 1 ) “锁”操作并不是具体访问类的主要功能，访问类主要功能应该是访问数 据对象，例如读取数据或写入数据。 ( 2 ) “锁”操作其实是可以和具体访问类的主要功能区分开来的。 可以说“锁”操作就是这个例子系统中的一个切面，它涉及许多类以及许多 类的方法。如图2 1 所示。 。领”处理 ff l 访问类1 卜 ii 厂) i访i 葡类2 1 少 _ j ， il i 访闻类nr 切 l l 面 图2 1 面向切面的示例 5 第2 章a o p 技术与i o c 模式概述 采用a o p 方法进行开发时关注的就是系统的切面，如这个例子中的“锁”操 作，开发人员应该对切面进行思考和编程。 如在这个应用例子中，“锁”操作切面应该有以下职责： 提供一些必备的功能，如对被访问对象实现加锁或解锁功能以保证所有在 修改数据对象的操作之前能够调用l o c k ( ) 加锁，在它使用完成后，调用u n l o c k ( ) 解锁。这就是a o p 面向切面编程的思想来源，也正是分散关注思想的一种体现。 2 1 2a o p 与o o p 的区别和联系 o o p 是在面向过程的编程方法基础上改进而来，而a o p 又是在0 0 p 的基础 上改进而来的一种新的软件开发方法。a o p 和o o p 虽然在字面上十分相似，但却 是面向不同领域的两种设计思想。o o p 针对问题领域中及业务处理过程中存在的 实体及其属性和操作进行抽象和封装，其目的是为了获得更加清晰高效的逻辑单 元划分；而a o p 则是针对业务处理过程中的操作切面进行提取。例如，在某个应 用系统中，多个模块都会涉及到数据验证的操作，那么这个数据验证操作就可以 看成是系统中各个模块的一个切面。在许多情况下，这样的操作都是与业务逻辑 相关性不强或者不属于业务逻辑操作必需的操作部分，o o p 很难对这种情况做出 处理，而a o p 则可以将应用程序中的业务逻辑处理部分和对其提供支持的通用服 务( 即所谓的“横切关注点”) 进行分离，使开发人员在编写程序时可以专注于业 务逻辑的处理。 使用a o p i o c 组合方式进行开发，首先要分析整理出系统中的“横切关注点”。 由于一个软件系统中通常会同时存在“纵向关注点”和“横切关注点”。因此开 发人员首先要利用a o p 技术各自独立的实现这些关注点；然后用i o c 模式将实现 “纵向关注点”和“横切关注点”的代码编织到一起。 图z 2 演示了由不同关注点组成一个系统，开发人员以a o p 切面的角度看待 这个系统。那么数据持久化、日志记录、系统安全等业务逻辑就会被认为是需要 解决的问题。因此，它们应该被当作关注点看待。从整个系统角度考虑，一个系 统往往是由大量的关注点构成的1 1 2 】。 6 基于a o p i o c 技术的数据验证组件的研究与实现 图2 2 把模块作为一批关注点来实现 如图2 3 所示，开发人员需要对系统需求进行拆分，区别出系统需求中存在 的不同关注点。 图2 3 关注点分解 开发人员利用a o p 方法把这些关注点封装在相应的模块中，可以避免o o p 引起的代码混乱和代码分散的问题，可增强系统的可维护性和代码的重用性。 2 1 3a o p 的术语定义 表2 1 给出了a o p 的部分术语定义【1 3 1 。 第2 章a o p 技术与i o c 模式概述 表2 1a o p 术语定义 t e r m 术语d e f i n i t i o n 定义 c o n c e r na 感兴趣应用的特定问题、概念、范围。例如，事务管理、持 p a r t i c u l a ri s s u e 久化、日志、安全等。 ( 关注特定问题) c r o s s c u t t i n gc o n c e r n 在关注点实现中贯穿了很多类，这在面向对象中通常很难实 ( 横切关注点)现和维护。 a s p e c t 模块化的横切关注点，通过代码的聚合和隔离实现 ( 切面) j o i np o i n t 在程序或者类执行时的一个点。 ( 连接点) p o i n t c u t 连接点的集合，这些连接点确认何时一个通知将会触发。切 ( 切入点)入点通常使用正则表达式或者是通配符语法 e a v i n g 装配切面来创建一个被通知对象。可以在编译期间完成也可 ( 编织) 以在运行时完成。 i n t e r c e p t o r一种a o p 实现策略，对与特点的连接点，可能存在一个拦截 ( 拦截器)器链。 2 2i o c 模式 l o c 模式是作为a p a c h ea v a l o n 项目创始人之一的s t e f a n om a z z o c c h i 提出的 一种代码调用模式，后被m a r t i nf o w l e r 改名为d e p e n d e n c yi n j e c t i o n ( 依赖注射) ， 也就是将类和类，方法和方法之间的关系通过第三方( 如配制文件) 进行“注射” 1 1 4 1 ，不需要类或者方法自己去解决彼此间的调用关系。在本文中统一将i o c 称为 依赖注入模式。 2 2 1l o c 模式概述 依赖注入模式的基本概念是：不创建对象，而是描述创建它们的方式。在代 码中不直接与对象和服务连接，而在配置文件中描述哪一个组件需要哪一项服务。 由容器负责将这些需求联系在一起。 在g o f 设计模式中，软件开发人员已经习惯了一种编程思维方式是接口驱动 ( i n t e r f a c ed d v e nd e s i g n ) 。接口驱动具有可以灵活的实现不同类型的子类、增加 代码稳定性和健壮性等优点。但是由于接口的声明仅仅给出了抽象方法，要具体 8 基于a o p i o c 技术的数据验证组件的研究与实现 的实现接口所规定的功能，则需某个类为接口中的抽象方法书写语句并定义方法 体，这就是接口的实现【1 6 1 ，也就是说如下的语句在程序代码中迟早要被执行。 a i n t e r f a c c l m p 是接口a i n t e f f a c e 的一个子类，采用l o c 模式可以延缓接口的实 现，做到根据需要实现接口。为了理解什么叫“注射”，f o w l e r 给出了一个形象 的比喻：程序中的接口就如同空的模型套子，在必要时向模型套子中注射石膏， 这样才能成为一个模型实体。因此，f o w l e r 将人为控制的程序接口的实现称为“注 射” 1 7 1 。 l o c 模式的目的是解决调用者与被调用者之间的关系问题，上述a i n t e r f a c e 实 现语句表明当前是在调用被调用者a i n t e r f a c e l m p ，由于被调用者名称写入了调用 者的代码中，调用者和被调用者有紧密联系，在u m l 中是用依赖d e p e n d e n c y 表 示。但是这种依赖在分散关注的思想下是不应该存在的，必须进行彼此间调用逻 辑的切割，实现调用者和被调用者解耦，i o c 模式的中心思想就是将调用者和被调 用者之间的依赖先剥离，然后在适当时候再通过配置文件来重新组织调用者和被 调用者之间的关联。 2 2 2i o c 模式实现的三种形式 表2 2 列举出了i o c 的三种实现方式【1 8 l 。本文中设计并实现的服务器端数据 验证组件就是采用了第一种类型的i o c 实现方式。 表2 2i o c 实现的三种方式 类型 方式应用领域 从j n d i 或s e r v i c e m a n a g e r 等获 le f b j 2 e e 第一种类型得被调用者，这里类似 2 a v a l o n ( a p a c h e 的一个复 s e r v i c e l o c a t o r 模式。 杂使用不多的项目) 1 s p d n gf r a m e w o r k ， 第二种类型 使用j a v a b e a n s 的s e t t e r 方法 2 w e b w o r k 1 p i c o c o n t a i n e r ， 第三种类型在构造方法中实现依赖 2 h i v e m i n d 9 第2 章a o p 技术与i o c 模式概述 2 2 3i o c 模式与e j b 工厂模式的比较 在j 2 e e 系统中，一般会划分为表现层、业务逻辑层和数据持久层为实现表 现层和业务逻辑层之间的最大限度解耦，由此产生了业务代理模式。这样，当表 现层或业务逻辑层发生变化时，对彼此的影响会很小。有过e j b 开发经验的人都 知道，为了实现调用者和被调用者问的解耦和分离，一般都是要通过e j b 工厂模 式这种业务代理模式来实现。 所谓工厂模式就是为了把对象的创建过程和使用过程进行分离，定义通用的接 口用于创建对象。工厂模式分为三种：简单工厂、工厂方法、抽象工厂【1 9 1 。 ( 1 ) 简单工厂模式( s i m p l ef a c t o r y ) 简单工厂是一个具体的全能类，负责产生所有的子类，它可以根据传的参数 进行比较，产生相对应的子类。 ( 2 ) 工厂方法模式( f a c t o r ym e t h o d ) 工厂方法是一个抽象的类或是接口。它只定义方法但不去实现方法实现方 法的任务具体由继承或是实现的子类来完成 ( 3 ) 抽象工厂模式( a b s t r a c tf a c t o r y ) 抽象工厂模式也是一个抽象的类，与工厂方法并没有多大的区别。关键在于 创建对象的复杂程度。 开发人员利用工厂模式为创建对象提供过渡接口，目的是想把对象的创建和 对象的使用过程分离使其可以自由变动，不会相互影响。但是工厂模式并没有完 全避免因为代码的改动而产生的对程序的影响。主要存在下面两个问题： ( 1 ) 类的生成代码被固定在程序里，如果需要更换一个子类，就要修改工厂 方法，这并不符合“高内聚、松耦合”的开发原则。 ( 2 ) 一个接口意味着一个生成工厂，如果一个项目中需要用到的接口很多， 那么系统中将会存在很多工厂类。这会使程序中充满了不必要的代码片断，导致 程序可读性差，修改和维护不方便等问题。 i o c 模式可以很好的解决这些问题，i o c 模式可以巧妙的把j a v a 的反射机制 和配置文件结合起来，可被看作是工厂模式的一种升华【加1 。i o c 就像是一个大工 厂，只不过这个大工厂里要生成的对象都是在x m l 配置文件中给出定义的，然后 利用j a v a 的“反射”机制进行编程，根据x m l 中的配置i d 名称来生成相应的对 基于a o p i o c 技术的数据验证组件的研究与实现 象。从实现角度来看，i o c 是把以前在工厂方法里必须要固定书写的对象生成代码， 改变为由x m l 文件来定义，也就是把工厂方法和对象生成这两者独立分隔开来， 可提高开发的灵活性和代码的可维护性。因为i o c 模式把对象生成放在了x m l 里 定义，所以当业务需求变更时，更换一个实现子类将会变得非常简单，只要修改 x m l 配置文件就可以了。这就像电脑硬件中使用的u s b 设备一样，实现了对使用 对象实例化进行热插拔。 i o c 模式也有它的不足之处，主要体现在执行效率上，由于使用了j a v a 的反 射原理进行对象的生成，在执行效率上会有些损耗【2 1 l 。但相对于l o c 提高的维护 性和灵活性来说，这点损耗是微不足道的，除非某对象的生成对效率要求特别高。 总之，使用i o c 模式，可以不管对象的具体实现，完全在一个抽象层次描述 技术架构，因此，i o c 模式可以为容器、框架之类的软件实现提供具体的实现手段， 属于架构技术中一种重要的模式应用。 2 2 4i o c 模式的优越生 在j a v a 中有一个基本定律，即在使用对象之前必须先创建这个对象。但是 现在开发人员可以不必一定遵循这个定律了。开发人员在进行代码开发时，可以 从i o c 容器中获得一个对象然后直接使用，无需事先创建它们。 这种变革就如同开发人员无需考虑对象的销毁一样，因为j a v a 的垃圾回收机 制帮助开发人员实现了对象销毁i 纠；现在有了l o c 模式，又无需考虑对象创建， 对象的创建和销毁都无需考虑了，这给编程带来的影响是深远和巨大的。 以下举个例子说明i o c 模式是如何不需要考虑对象的创建的，有一个普通类b 代码如下： 第2 章a o p 技术与i o c 模式概述 有两种使用b 的方式： ( 1 ) 普通无i o c 模式的调用方式 b ib = n e w b ( n c wa o ) ；需要在生成b 实例之前生成a 等实例 b i n v o k e 0 1 ( 2 ) 使用l o c 模式的调用方式 b ib = ( b d w e b a p p u t i l g c t s e r v i c e ( b ) ； b i n v o k c 0 ； 很明显的可以看出采用上面两种方式重要区别。 前者需要照顾b 类中a 类的实例化，如果b 类中调用不只a 类一个，还有更 多其它类如c d e 等类，这样，开发人员在使用b 类时，还需要研究其它类的创 建，如果c d e 这些类不是由开发人员自己编写，开发人员还需要翻阅它们的a p i 说明，研究它们应该如何创建，是使用n e w 还是工厂模式还是单态调用。仅仅为 了使用b 类中一个小小的方法，就将花去开发人员大量的时间和精力 而当使用第二种方式时，就无需花很多精力和时间考虑a ，c ，d 也等类的创建。 使用i o c 容器，再也不必做这些复杂的工作了，开发人员只需从l o c 容器中抓取 一个类然后直接使用它们。 当然，在使用之前，需要做一个简单的配置，把开发人员将来需要使用的类 全部告诉l o c 容器，配置a p p l i c a t i o n c o n t e x t x m l 如下1 2 町： 可见，i o c 模式将原来纠缠在一起的构件模块分割成一个个相对独立的类，如 果把开发程序比作建筑一个大厦，那么当开发人员将将要建造一个大厦细分为沙 粒时，就可以使用沙粒来组合任何一个建筑了，这体现了未来面向构件化编程的 一个发展方向。i o c 模式的过人之处就在于使得设计非常灵活，有些组件化的感觉。 基于a o p i o c 技术的数据验证组件的研究与实现 构建一个系统就像搭积木，可以把所有的模型和服务统称为s e r v i c e ，开发人员提 供的s e r v i c e 的多少决定了开发出来的的系统具备哪些具体的功能。而这些 s e r v i c e 就相当于每块积木，而s e r v i c e 之间的关联相当于积木怎么摆放，这就看 软件开发人员的想象力有多丰富。积木搭建的漂亮就说明开发人员的业务层做得 是比较完善的。 第3 章数据验证技术分析与研究 第3 章数据验证技术的分析与研究 3 1 数据验证技术 3 1 1 数据验证概述 在r r 行业当中，w e b 的开发历史可以算得上非常悠久了。自从动态页面技术 出现以来，w e b 开发的热潮更是不断涌现，如今已经发展到w c b2 0 的阶段。动 态页面技术如a s p 、j s p 、p h p 的出现，使各种服务能够实现。如此便出现了为数 众多的服务提供商，这些服务的提供者不仅使用动态页面技术提供更加合理的内 容显示，而且还逐渐增加了诸如电子邮件、个人空间、网络交友，论坛讨论等一 系列的花样繁多的功能【2 5 】。层出不穷的服务功能中绝大多数需要与用户进行交互。 在和用户的交互过程中，或多或少都需要用户进行不同内容，不同样式的数据输 入。在用户与系统的交互过程中，为了确保用户输入数据的完整性和合法性，通 常会对用户输入的数据进行数据验证。 所谓数据验证，是指在进行后续处理动作以及把用户输入的数据存储到数据 库之前，确保数据的完整性和合法性的过程【矧。 3 1 2 数据验证方式分类 数据验证按照所处理的验证逻辑复杂程度可以分为表单级别验证和业务逻辑 级别验证两种形式【卅。 ( 1 ) 表单级别数据验证 所谓表单级别验证，是指确保所有数据类型( i n t 、f l o a t 、s t r i n g 等) 都是正确 的，还要确认变量的值都在允许的范围之内。本质上，表单级别验证主要是验证 用户输入数掘的正确性和合法性，并可强制用户输入符合规则的数据。 ( 2 ) 业务逻辑级别数据验证 业务逻辑验证是指基于一组业务规则的验证方式。例如，用户要查询一个时 间区间为2 0 0 0 2 0 0 6 之间的数据，如果用户的输入是2 0 0 6 2 0 0 0 ，这虽然符合表单 级别的验证，但是却不符合业务逻辑级别的验证，也会造成业务逻辑错误。因此， 业务逻辑级别的验证是在表单级别验证基础之上的更高级的验证方式。 1 4 基于a o p i o c 技术的数据验证组件的研究与实现 按照数据验证在j 2 e e 分层开发模型中所处的位置，可以把数据验证分为客户 端验证和服务器端验证两种情况【刎。 ( 1 ) 客户端验证 在w e b 应用中，当用户在所浏览的页面中输入了不同的数据信息后，会通过 单击一个按钮或者一个链接来进行下一步的操作，称之为用户向服务器发出了一 个请求，而服务器向用户发出的反馈信息称为一个响应。客户端验证就是指在发 出请求之前就对用户输入的数据进行验证。通常这种方式都是通过j a v a s c r i p t 等脚 本语言来实现的【冽。 ( 2 ) 服务器端验证 服务器端验证是指在客户端和服务器端的请求一响应过程中，将页面表单元素 提交到服务器，由服务器端执行验证逻辑，然后再将结果返回到客户端的验证过 程。 3 2 服务器端数据验证的重要性 对于一个j 2 e e 企业级应用来说，数据验证的功能也许并不是最重要的，但是 却是必需的。一个企业级应用系统在数据验证方面的能力，在相当程度上体现了 这个企业级应用系统的质量。很多开发人员只选择在客户端进行数据验证，事实 证明这很不安全。一旦用户设置浏览器禁止运行脚本代码，则所有客户端的验证 都会失效。如果碰到别有用心者，通过s q l 注入等手段侵入数据库，甚至会对整 个系统的安全性构成威胁。 2 0 0 6 年互联网安全评估报告中有一篇文章( t o p1 0w e b2 0a t t a c kv e c t o r s ) 1 2 9 j 总结出了对砰e b 构成威胁的十大因素，其中客户端编码中的数据验证被排在了 w e b 威胁中的第六位。其中详细说明了如果开发人员只依赖客户端数据验证，不在 服务器端重新进行数据验证的话，会导致s q l 注入等系统安全方面的威胁。 根据基于亚特兰大的s c c u r c w o r k s 公司的调查【删，他们的1 3 0 0 个客户的数据 库遭受的攻击竟高达每天8 0 0 0 余次。这些黑客，大多数采用的是s q l 注入攻击法。 他们先从g o o g l e 的搜索引擎中找到有表单的网页，然后在表单数据里注入恶意的 s q l 语句或指令，由于很多w e b 应用并不对表单里的数据进行验证，这些语句或 指令往往能够在数据库系统里被成功执行。然后他们用工具从数据库里收集信息， 1 5 第3 章数据验证技术分析与研究 进而注入更多编码，导致数据库系统从网上自动下载能让黑客控制服务器的程序。 由于s q l 注入攻击的对象往往很集中，如金融机构等，因此不会象广泛传播的病 毒一样容易被人瞩目，但是带来的危害却是十分严重的，如c a r d s y s t c m ss o l u t i o n s 是一家负责处理信用卡付款数据的公司，一个黑客使用s q l 注入攻击安装了一个 程序，把信用卡数据每隔四天传到一个远程计算机上，收集了4 千万个信用卡号 码，涉及的银行汇报的受损金额达数百万美元。 可见，要想保障数据库乃至整个应用系统的安全性和健壮性，除了采用好的 数据库产品之外，对将要保存到数据库中的数据进行合理有效的验证也是必不可 少的。从整体考虑来说，一个健壮的、设计良好的数据验证体系，应该是既有客 户端验证同时也应该具备服务器端验证的能力。由客户端验证来提供良好的人机 交互界面，而由服务器端验证提供真正应用程序级的安全。 3 3 目前服务器端数据验证方式的不足之处 e j b 框架允许在每个动作类中进行对输入数据的验证工作。为了对将要传给应 用程序的数据做验证的工作，开发人员必须在每个动作类中为想验证的数