（计算机应用技术专业论文）基于ioc和aop的服务框架核心研究与设计.pdf

西南交通大学硕士研究生学位论文第1 页 摘要 目前的应用软件产品大多基于p c ，随着移动通信网络的飞速发展以及手 持终端硬件性能的大幅度提高，作为对行业应用软件的有益补充和扩展，在手 持终端上进行产品开发的软硬件条件已经具备。 在服务器系统开发中，j 2 e e 服务架构在分布式系统的设计、集成、性能、 安全性和可靠性等诸多方面为开发人员提供了详细规范，提高了系统的灵活 性、可伸缩性，已成为当前行业应用软件开发的主流架构，并以其卓越的平台 无关性、可移植性、架构开放性、安全性获得了广泛的应用。然而随着面向对 象的j a v a 语言和j 2 e e 构架的发展，人们逐渐意识到单纯的0 0 不能很好的解 决所有系统设计的问题，而j 2 e e 构架的重量级组件给系统开发和测试带来了 很大的困难，造成了很多项目的失败，近来，反转控制( i o c ) 和面向方面编程 ( a o p ) 这两种新的软件设计方法开始出现和流行，其设计思想被不断的融入到 系统设计中，给软件系统带来了新的活力“”1 。 本课题针对无线移动数据应用的开发框架f r a m e s e r v e r 为背景，对i o c 和a o p 的构架和算法进行了深入研究，实现了f r 硼e s e r v e r 的核心一i o c 微容 器和动态a o p 引擎，并通过m v c 模式构架了f r a i i i e s e r v e r 的m v c 框架，实现了 对多种终端的并发接入支持。 论文首先对软件工程中新兴的反转控制模式( i n v e r s eo fc o n t r 0 1 ) 和面向 方面编程( a s p e c t e do r i e n t e dp r o g r a 哪i n g ) 做了简单的介绍，阐述了 f r a m e s e r v e r 框架的设计思想和体系结构设计；从结构和性能两方面深入探讨 了f r a m e s e r v e r 框架的i o c 微容器和动态a o p 引擎的核心算法；同时结合实际 项目“什邡卷烟厂移动数据中心”介绍了f r a m e s e r v e r 框架在无线数据系统开 发中的应用；最后总结了f r a m e s e r v e r 框架的特点和相关技术下一步的发展方 向。 关键字反转控制，面向方面编程，框架，m v c 模式，手持终端 西南交通大学硕士研究生学位论文第1 i 页 a b s t r a c t n o w a d a y s ；p r o d u c t so fa p p l i c a t i o ns o f t w a r ea r em o s t l yb a s e do np c w i t ht h er a i dd e v e l o p m e n to ft h em o b i l ec o 哪u n i c a t i o nn e t 哥o r ka n dt h e r e m a r k a b l ee n h a n c e m e n to ft h eh a r d w a r ep e r f o r m a n c eo fh a n d s e t ， a sa u s e f u l s u p p l e m e n t a n de x t e n s i o nf o r a p p l i c a t i o ns o f t w a r e s ，t h e c o n d i t i o nf o rb o t hs o f t w a r ea n dh a r d w a r ef o rd e v e l o p i n gp r o d u c t so n h a n d s e th a sb e e nr e a d y i nt h ed e v e l o p m e n to ft h es e r v e rs y s t e m s ，j 2 e es e r v i c ea r c h i t e c t u r e p r o v i d e sd e v e l o p e r sd e t a i l e ds p e c i f i c a t i o n si nd e s i g n ， i n t e g r a t i o n ， p e r f o r m a n c e ，s e c u r i t ya n dr e l i a b i l i t yo ft h ed i s t r i b u t e ds y s t e m ，w h i c h h a sb e c o m et h em a i n s t r e a ma r c h i t e c t u r ei nc u r r e n ts o f t w a r ed e v e l o d m e n t b e c a u s eo ft h ei m p r o v e m e n tf o rs y s t e m sa g i li t ya n df l e x i b i l i t y i ti s a l s ow i d e l yu s e db e c a u s eo fi t sp l a t f o r mi n d e p e n d e n c y ，t r a n p l a n t a t i o n ， o p e na r c h i t 譬c t u r ea n ds e c u r i t y b u tw i t ht h ed e v e l o p m e n t + o ft h ej a v a l a n g u a g ea n dj 2 e ea r c h i t e c t u r e ，p e o p l ea r eg r a d u a l l ya w a r eo ft h a tp u r e o oc o u l dn o t s o l v ea l lt h ep r o b l e m si nt h es y s t e md e s i g n ，a n d 。t h ef a i l u r e o fm a n y p r o j e c t sr e s u l t f r o mt h e h e a v yc o m p o n e n to ft h ej 2 e e a r c h i t e c t u r ew h i c hb r i n g sd i f f i c u l t i e si ns y s t e m sd e v e l o p m e n ta n dt e s t r e c e n t l y ，a st h en e ws o f t w a r ed e s i g na p p r o a c h ，i n v e r s eo fc o n t r 0 1 ( i o c ) a n da s p e c t e do r i e n t e dp r o g r a m m i n g ( a o p ) w e r eb o r na n dh a sb e c o m em o r e a n dm o r ep o 西u l a r ，t h ei d e ao fw h i c hw e r e i n t e g r a t e di n t ot h es y s t e m d e s i g na n db r o u g h tt h en e we n e r g yf o rt h es o f t w a r es y s t e m “m 1 t h i st h e s i si so nt h eb a c k g r o u n do ft h ef r 铷l e w o r kf r a m e s e r v e rw h i c h i sd e s i g n e df o rw i r e l e s sm o b i l ed a t aa p p l i c a t i o n s ，t h ea r c h i t e c t u r ea n d a l g o r it h m so ft h ei o ca n da o pa r er e s e a r c h e di nd e d t h a st h ek e r n e l o ft h ef r a m e s e r v e r ，a ni o cb a s e d m i c r oc o n t a i n e ra n dad y n a m i ca o pe n g i n e w e r ei m p l e m e n t e d ，a l s oam v cf r a m e w o r kf o rf r a m e s e r v e rw a se s t a b l i s h e d w i t hm v cp a t t e r n ，w h i c hp r o v i d e sc o n c u r r e n ta c c e s sf o rm u l t i t e r m i n a l s i nt h i st h e s i s ， f i r s t l y ， i o cp a t t e r na n da o pr i s i n gi ns o f t w a r e e n g i n e e r i n g a r e b r i e f l yi n t r o d u c e d ，a n dt h ed e s i g ni d e a sa n d a r c h i t e c t u r eo ff r a m e s e r v e rf r 锄e w o r ka r ed i s c u s s e d t h e nt h ec o r e 西南交通大学硕士研究生学位论文第1 i i 页 a l g o r i t h m so ft h ei o cb a s e dm i c r oc o n t a i n e ra n dt h ed y n a m i ca o pe n g i n e a r ei n t r o d u c e d w i t he m p h a s i st h r o u g ht h ea s p e c t so fs t r u c t u r ea n d p e r f o r m a n c e a sw e l l ，t h ea p p l l c a t i o no ff r a m e s e r v e ff r a m e w o r ki nt h e d e v e l o p m e n to fw i r e l e s sd a t as y s t e mi si n t r o d u c e dw i t h a n a c t u a lp r o j e c t “s h i f a n gt o b a c c oc o m p a n ym o b i l ed a t ac e n t e r ” f i n a l l y ， t h ef e a t u r e o ff r a m e s e r v e rf r a m e w o r ka n d t h ep r o s p e c to fr e l e v a n tt e c h n i q u e d e v e l o d m e n ta r ee x d l a i n e da sac o n c l u s i o n k e yw o r d s ：i n v e r s eo fc o n t r o l ，a s p e c t e d0 r i e n t e dp r o g r a m m i n g ，f r a m e w o r k m v cp a t t e r n h a n d s e t 西南交通大学硕士研究生学位论文第l 页 1 1 课题背景 第1 章绪论 企业为了在激烈的市场竞争中求得生存和发展，都在加速自身的信息化建 设进程，众多的企事业单位对信息交换的要求，已由“固定的、限时的模式” 转变为“不受地域、时间限制的、随时进行的模式”，目前，企业内部行业应 用软件种类繁多，但人员出差的频繁、经营范围的扩展、应变速度的提升等使 得各企业时常面临许多难题：延误工作； 应急反应差； 企业决策信息滞后； 信息分散难以满足用户“随时、随地、随身”的信息处理需求。 显然，原有的计算机网络及软件系统已经不能满足要求。对于工作具有流 动性、实时性的人群，无线网络技术成为重要的解决手段。 目前，移动增值业务开发和应用主要集中在娱乐领域( 如手机游戏，图铃下 载) ，随着移动通信网络的快速发展和无线手持设备硬件性能的大幅度提高， 企业对无线移动数据访问的需求也越来越迫切。开发基于移动终端的企业信息 平台( m o b i l ee n t e r p r i s ei n f o r 眦t i o np 1 a t f o r m - m e i p ) 有着很大的市场前景， 移动终端和传统浏览器的集成也有很大的实用价值。 j 2 e e ( j a v a2e n t e r p r i s ee d i t i o n ) 体系结构以其安全、跨平台等优点 已经逐渐成为企业应用开发的标准，提供了一个企业级的计算模型和运行环 境，用于开发和部署多层体系的应用n ”。 1 。2 研究现状和问题 在手机为载体的信息浏览工具中，w a p ( w i r e l e s sa p p l i c a t i o np r o t o c 0 1 ) 测览器目前已经普遍支持，但是由于其功能低下，不能满足企业管理系统中各 种复杂的展示界面，而新兴的j 2 m e 和b r e w 嵌入式开发平台所提供的强大用户 西南交通大学硕士研究生学位论文第3 页 象之前必须创建对象的定律；i o c 模式通过i o c 微容器实现，所有组件都被注 册在容器中，由容器负责组件的创建、销毁和依赖关系管理等功能；同时i o c 模式也强调组件的简单性和独立性，对容器不产生依赖性m 。而a o p 是一种新 的编程方式，它是对0 0 p 更高层次的抽象，它使用分散关注的思想，通过方面 代替对象获得了比o o p 更高的组件复用率；a o p 是通过a o p 引擎实现的，现在 提出了静态和动态两种编译引擎。这两种理论都处于刚起步的阶段，还不成熟， 所以它们的研究有着很重要的意义一，。 1 3 本文所做的工作及结构安排 在理论研究方面，从基于j 2 e e 的服务器框架系统的研究角度出发，深入 研究了i o c 和a o p 理论的模型和实现算法，实现了完全基于元数据的自动化 i o c 微容器和基于字节码迁移的高性能动态a o p 引擎n ”n ”。 在应用系统方面，结合无线移动数据的特点，并融合i o c 微容器和动态 a o p 引擎，负责设计了能够支持多终端并发访问的轻量级m v c 增值业务开发框 架一f r a l i l e s e r v e r ，并实现了框架的反转控制( i o c ) 容器，动态a o p 引擎，肼c 子 框架和大部分组件库j 该框架能够同时实现对1 i j e b ，w a p ，j 2 m e ，腿e w 和s m 的并 发访问支持。和目前流行的j 2 e e 框架相比，由于f r a m e s e r v e r 有了i o c 容器 和动态a o p 引擎的支持，应用系统开发具有更松散的耦合和更高的组件复用 率，同时基于i o c 模式设计的组件也能够很好的满足测试驱动“e s td r i v e n ) 的开发模式n ”。此外，本文结合实际的无线数据项目什邡卷烟厂移动数据中 心介绍了如何使用f r 鲫e s e r v e r 框架进行移动数据系统开发。 分为七个部分来阐述： 1 绪论 介绍课题的背景、意义，相关理论、技术研究现状，对论文工作及结构安 排进行概要介绍。 2 反转控制和面向方面编程 介绍了目前在软件工程领域新兴的反转控制模式( i n v e r s eo fc o n t r o l i o c ) 的基本思想，以及反转控制在组件设计中的优势；同时介绍了面向方面 编程( a s p e c to r i e n t e dp r o g r 锄i n g a o p ) 的出现背景，基本概念以及a o p 的 优势和目前的发展状况。 3f r a m e s e r v e r 的体系结构设计 西南交通大学硕士研究生学位论文第4 页 详细的介绍了f r a m e s e r v e r 框架的设计思想和体系结构设计。 4f r a m e s e r v e r 的i o c 微容器和核心算法 详细介绍了f r a i i i e s e r v e r 框架的i o c 微容器结构设计和核心算法的实现。 5 f r 踟i l e s 8 ：v e r 的动态a o p 引擎和核心算法 详细介绍了f r 鲫e s e r v e r 框架的动态a o p 编译引擎的结构设计和核心算法 实现。 6f r a m e s e r v e r 在无线数据系统中的应用 以实际项目什邡卷烟厂移动数据中心为例，介绍了在无线数据系统中 使用的数据协议m d a t a 的设计以及如何开发基于f r a i i l e s e r v e r 框架的无线数据 系统。 7 研究工作总结与展望 西南交通大学硕士研究生学位论文 第5 页 第2 章反转控制( i o c ) 和面向方面编程( a o p ) r 反转控制和面向方面编程是两种新兴的软件方法学，对系统组件的解耦和 提高组件复用率有显著的效果绍。 2 1 反转控制( i n v e r s eo fc o n t r 0 1 ti o c ) 反转控制( i o c ) 是一种新兴的设计模式，它关注组件的装配方式，其目的是 将来自不同项目的组件组装成为一个高度内聚的系统。本节将深入探索反转控 制模式的思想和工作原理，并将其与传统的工厂模式( f a c t o r y ) 和服务定位器 模式( s e r v i c el o c a t o r ) 进行比较。这些模式的共同目标虽然都是将组件的 配置与使用分离，但是i o c 和这些模式相比有着很明显的优势。 在o p e ns o u r c e 社群里，有很多人投入大量精力来研究主流j 2 e e 技术的 替代品，并提供了很多有意义的可供选择的方案。j 2 e e 开发者常遇到的一个 问题就是如何姐装不同的组件元素，例如w e b 控制器体系结构和数据库接口是 由不同的团队所开发的，彼此几乎无所知，应该如何让它们配合工作? 很多 框架尝试过解决这个问题，结果都不尽如人意，然而在一些相关的设计模式( 如 i o c ，c 0 p ) 出现以后，提供了更通用的“组装各层组件”的方案，这样的框架通 常被称为“轻量级容器”，著名的有a v a l o n 和s p r i n g 框架，而f r a e s e r v e r 作为一个更轻量级的企业框架，使用元数据驱动实现了轻量级容器。在这些容 器背后，一些重要的设计原则发挥着主导的作用。这里使用j a v a 作为范例代 码揭示这些原则，这些原则也同样适用于别的0 0 环境，例如c 十+ 和n e t 环境。 2 1 1 组件和服务 i o c 模式与组件密切相关，在本文中所定义的组件( c o m p o n e n t ) 是指这 样一个软件单元：它将被作为无法控制的其他应用程序使用，但后者不能对组 件进行修改。也就是说，使用一个组件的应用程序不能修改组件的源代码，但 可以通过作者预留的某种途径对其进行扩展，以改变组件的行为。服务和组件 有某种相似之处；它们都将被外部的应用程序使用。作者认为，两者之间屉大 有某种相似之处；它们都将被外部的应用程序使用。作者认为，两者之间虽大 西南交通大学硕士研究生学位论文第6 页 的差异在于：组件是在本地使用的( 例如j a r 文件、程序集、d l l 、或者源码 导入) ；而服务( s e r v i c e ) 则需要通过同步或异步的远程接口来使用( 例如w e b s e r v i c e 、消息系统、r p c ，或者s o e k e t ) 。由于组件和服务具有共同的特点， 在没有特别说明的情况下，均使用组件来指服务或组件。 2 1 2 核心问题 在一个真实的系统中，可能存在数十个服务和组件。在任何时候，系统设 计人员总可以对使用一定意义的组件加以抽象，通过接口与具体的组件交流 ( 即使组件并没有设计一个接口，也可以通过适配器与之交流) 。但是，如果 希望以不同的方式部署这个系统，就需要用插件机制来处理服务之间的交互过 程，这样我们才可能在不同的部署方案中使用不同的实现。核心问题是如何将 这些插件组合成一个应用程序，很多的设计模式( 如f a c t o r y 模式) 都在试图解 决这个问题，而都没有使这个问题得到很好的解决。 直到2 0 0 4 年m a r t i nf o w l e r 提出反转控制( i n v e r s i o no fc o n t r 0 1 ) 模 式，才让这个问题从根本上得到了解决“。，。 2 1 3 反转控制模式和反转控制框架 反转控制的思想来源于电影界的好莱坞原则( h 0 1 l y w o o dp r i n c i p l e ) 一 “你不要来找我们，我们有事情会找你”w 。作为新兴的设计模式，反转控制 模式是_ 个组件创建模式，反转控制将组件的创建方式进行了反转，它要求组 件的创建是一个被动过程，它不能被另外一个组件直接创建，必须由一个特殊 的反转控制框架来负责，即一个完全基于反转控制模式的系统没有任何组件的 创建代码；组件设计应该是基于插件的，符合d i p 原则，同时组件必须遵循一 定的规则来说明自己需要的组件( d e p e n d e n c y ) 或服务，创建点也由应用程序转 移到了基于反转控制的框架中，由框架维护组件之间的依赖关系。 传统组件的使用和创建都是由应用程序主动发起的，用户需要一个组件， 就必须创建一个组件对象，这样的模式需要用户自己去维护组件之间的代码依 赖关系，不可避免的会产生组件耦合。那么对应用来说，如果需要一个组件， 只需要告诉框架，框架就会组装一个组件给应用程序使用，应用程序不再需要 负责组件的创建工作，耦合问题就可以得到很好的解决。实质上，反转控制框 西南交通大学硕士研究生学位论文第7 页 架解决的是“如何定位插件的具体实现”的问题。 反转控制框架则根据反转控制模式使用了更为灵活的方法，只要插件遵循 定的规则，反转控制容器就能够将插件的具体实现“注入”到应用程序中，所 以反转控制也被称为“依赖注入”( d e p e n d e n c yi n j e c t i o n ) 模式。反转控制 模式要求组件遵循一定的规则说明所依赖的组件，以便让框架实现依赖注射， 那么根据规则的不同，可以将反转控制模式划分成的几种不同类型。 依赖注入的几神类型 目前依赖注入的形式主要有三种，它们分别被称为t y p eli o c ( 接口注 入) 、t y p e2i o c ( 设值方法注入) 和t y p e3i o c ( 构造子注入) 。 以一个组件为例，该组件提供一份电影清单，清单上列出的影片都是由一 位特定的导演执导。 首先需要定义如下m o v i e f i n d e r 接口： p u b l i ci n t e i f a c em o v i e f i n d e r u s t f i n d a 】1 0 ； 一般的做法是把“涉及具体子类”的代码放在m o i i e l i s t e r 类的构造子 电： d a s sm b v i e u s t e l p d v a i em o v i e f i d e r 血d e r ； p u b l i cm 0 v i e u s t e r o f i n d e r = m w c o l o n d e l i n l i t e d m o v i e 硒d e 吖m o v i e s l t x t ”) ； 本文中的f r a i n e s e r v e r 框架使用一个微容器i o c c o n t a i n e r 作为反转控制 框架同时实现了三种i o c 模式( 事实上i o c c o n t a i n e r 还支持其他类型的依赖注 入，由于篇幅关系不在这里介绍) ，下面以i o c c o n t a i n e r 为例分别说明这三种 注入模式。 构造子注入( t y p e 3 ) 在进行构造子注入时，i o c c o n t a i n e r 会通过分析构造子元数据来构i 酽如 何将m o v i e f i n d e r 实例注入m o v i e l i s t e r 类”。因此，m o v i e l i s t e r 类必须声 明一个构造子，并在其中包含所有需要注入的元素： d a s sm o v i e u s t c l 。 p u b cm o v i e u s l e r ( m o v i c f i n d e r 丘n d e r ) 西南交通大学硕士研究生学位论文第l o 页 ) 这个接口应该由m o v i e f i n d e r 接口的提供者来提供。任何需要 l o v i e f i n d e r 实例的组件类( 如m o v i e l i s t e r 类) 只需要实现这个接口。 d a s jm o v i e “s c c ri m p 】e m e n t sf i n d e i a a r e p u b l i cv o i ds e t 胁d e r ( m o v i e f i n d e rf i n d e r ) t h i s f i n d 盯= f i n d e r ： ) 同理，使用类似的方法将文件名注入m o v i e f i n d e r 的实现类： p u b l i ci n t e r f a c ef i k n a n 碡j a w a r e v o i d t f i l e n a m e ( s l f i n gm e n 枷e ) ； d a 鳃c o l o n m o v i e r 帕e ri m p l 嘲蛐t sm o v i e f i n d e f i l e n a m e a w a r c p u b cv o i d 佩e 蚰m e ( s t i i n gn k n a m e ) 也i s 蜘e n a m e = f i l e m m e ： ) 最后就可以将这两个组件注册到容器中使用，其配置方法与构造子注入完 全相同。 需要指出，和前面两种注入方式相比，接口注入会给组件带来接口压力， 不利于组件间移植。 2 1 4 反转控制模式和其他创建型模式的比较 2 1 4 1 反转控制模式和工厂模式( f a c t o r y ) 对类的创建模式而言，目前用的最多的要算工厂模式，在工厂模式中一个 工厂类负责一类产品的创建，工厂是调用者与被调用者的联系点。该模式能在 一定程度上解耦调用者与被调用者，但在类的调用者中始终存在着关于工厂的 代码部份，工厂部份又和被调用者相联系，所以调用者与被调用者之间还是耦 合的。这样一旦被调用者发生变化就涉及到对工厂类和调用者的修改，这对于 一个大的系统来说将是一个耗时的过程，其效率也不高；从分散关注的思维方 式来说，如果能将工厂从调用者中解耦出来，将调用者与被调用者在一个统一 的位置进行关联，则可以在较大程度上提高系统的性能。而反转控制模式将调 西南交通大学硕士研究生学位论文第u 页 用者与被调用者的组装与联系放入框架中，由反转控制框架来发现类创建过程 中的依存关系，这样在应用系统组件中可以完全消除工厂代码”1 。下面分别对 基于这两种模式的组件进行分析。 在工厂模式中，调用者和披调用者组件之间是通过工厂来进行解耦的。假 设有类a 和接口b ，其中，a 为调用者，b 为被调用者，b i m p l 为b 的一个具体 的实现类。如果a 要调用b 的b i m p l 实现类，由工厂返回其实现类对象，如下 面的代码所示： p u b n cc l a s s a p f i v a c e bb ； p 由a t cf i n a ls l a t i cm y f a c c o r ym y f a c t o r y = m y f a d o 珥g e 血s t a n o ； p 曲c a 0 t l l i s b ；m y f a c t 0 珥c r e a t e l n s t 粕c c o 毋0 ；，返回b 的实现类b i m 一 ) p u b l i cv o i d m m e l h o d 0 也i s b y l i e l l o o ) 在运行期，m y f a c t o r y 根据所定义的b 的实现类b i m p l ，通过 c r e a t e i n s t a n c e o f b ( ) 创建b i m p l 的对象。这种方式在一定程度上实现了调用 者和被调用者的解耦，但在a 的代码存在的工厂和b 还是有间接联系的，而且 b 的创建过程是一个主动过程，即是由a 要求创建b 的对象，a 需要干涉b 的 创建过程，所以，还没有彻底解耦a 与b 。 而使用反转控制模式可以实现接口a 和接口b 的实现b i m p l 的完全解耦， 让a 完全不需要察觉b i m p l 的存在。采用构造子注入方式为例对上述组件重构 如下： p u b l i cd a s s a p r i v a t e bb ； p u b l i c a ( bb ) t h i s b = b ： p i l b l i cv o i ds o m e m e l h o d o 西南交通大学硕士研究生学位论文 第1 2 页 m i s b s a y h e l l 0 0 ； ) 可以看出，通过构造子声明依赖组件，类a 变得更加简洁，消除了所有关 于b 的工厂代码，a 的依赖对象b 由构造函数的参数获取，a 和b i m p l 之间没 有任何联系，a 不需要关心b i m p l 的创建过程，只需要使用接口b 完成逻辑操 作。 实质上，a 和b i m p l 之间的依赖关系并没有消失，而是被转移到了反转控 制框架中，由框架来管理对象之间的依赖关系，f r a i i l e s e r v e r 的i o c 容器使用 反转控制实现了比f a c t o r y 强的功能，提供了多种与注册时序无关的自适应注 入模式。 在f r a i n e s e r v e r 中，如果客户端代码需要调用b 的实现子类b i m p l 时，就 可以借助容器来实现，使用下列代码： p u b l i cd a $ d i e n t p u b h cs t a 雠v o i dm a i h ( s i n g 【】a i g s ) m u t a b k i o c o t a i 嘣c o n t a i 玳f = n e wd e f a u l i i o c c o n l a i 北ro ； c o n t a i n e l 糟西s i e r 饵i m p l d 筋s ) ；注册b 的实现类b i n l p l c o n t a i n e l 托g i s t e r ( a d a s s ) ； 膪器完成组件的验证和装配过程 c o n 倒n e l v e r i f y o ； a a = c o n t a i n e f g e t 自谳n c e ( a c l a s s ) ；，从容器中获取a 的对象 a s o m e m e t h o d 0 ； 可以看出，上面代码没有使用任何n e w 语句来创建任何组件对象( a ，b i m p l 等) ，这是反转控制模式的一个特点，它将a 和b 的联系点转移到了i o c 容器 中，使组件自身具有了更好的简单性和开放性。1 。 由于两种模式的不同特点，使得系统在需要扩展和修改时具有不同的性 质：在系统需要修改时，传统工厂模式不仅涉及到组件的修改，更麻烦的是要 对工厂进行修改；在反转控制模式中，不存在任何关于工厂类的修改；且在有 组件需要更换的情况下，工厂模式要对工厂和调用者同时进行修改；而采用反 话南交通大学硕士研究生学位论文第1 3 页 转控制，只需在客户端对注射到容器中的组件名进行替换，避免了工厂这一中 间环节。在系统需要增加新的接口时，传统工厂模式同时要增加相应的工厂子 类，而反转控制模式中就不存在对这些代码的增加，系统扩展更加方便。 此外，通过i o c 容器管理s i n g l e t o n 对象可以很好的避免s i n g l e l o n 反模 式( a n t i p a t t e r n ) ；而工厂模式对s i n 9 1 e t o n 对象采用手工管理，在上下文不 正确的情况下可能造成严重的后果，反转控制模式和工厂模式的对照关系如表 2 1 所示m ，： 表2 1工厂模式与i o c 模式对照表 2 1 4 2 反转控制模式和服务定位器模式( s e r v i c el o c a t o r ) 服务定位器是j 2 e e 构架的标准核心模式w ，它和工厂模式的结构大致相 同，但是应用环境不同，主要应用在像e j b 这样的远程服务调用上，和反转控 制模式一样，服务定位器也提供了基本的解耦能力w 。两者之间本质的区别在 于：“组件实现”以什么方式给应用程序提供代码。使用服务定位器模式时， 应用程序代码直接向服务定位器发送一个消息，明确要求服务的实现；而使用 反转控制模式时，应用程序代码不发出显式的请求，服务的实现出现在应用程 序代码中：在使用服务定位器模式时，和工厂模式的缺陷一样，服务的使用者 必须依赖于服务定位器，定位器可以隐藏使用者对服务具体实现的依赖，但必 须首先得到定位器本身的引用。反转控制模式可以帮助开发人员看清组件之间 的依赖关系：只需观察依赖注入的机制( 例如构造子) ，就可以掌握整个依赖 关系。而使用服务定位器模式时，必须在组件代码中搜索对服务定位器的调用。 同工厂模式和服务定位器模式相比，反转控制模式最明显的优势在于将调 用者与被调用者的联系点进行了转移。在工厂模式和服务定位器模式中，调用 者与被调用者的联系点在调用者的代码内，实际上是一种间接的硬编码方式； 而反转控制模式将这种联系放到了框架中，也就是说将分散于多个调用者中的 联系点统到框架，由框架统一进行组件的组装，在调用者的代码中不再出现 西南交通大学硕士研究生学位论文第1 4 页 关于被调用者细节的代码m 。这样调用者就无需去了解被调用者的具体实现细 节，只需对其接口负责，更好的解耦了调用者与被调用者。反转控制模式较传 统模式而言本质是进行了关注点转移，9 对于f r 硼e s e r v e r 来说：i o c 容器提供 了组件透明使用动态a o p 代理的先决条件n ”。 2 2 面向方面编程( a s p e c t e d0 r i e n t e dp r o g r 锄i n g a o p ) 2 2 1a o p 起源 传统的编程技术，采用分解的方式将一个软件系统划分为相对较小的、易 于分析、理解的模块，如果这些模块仍难以分析、理解，则用迭代方式将其分 解为更小的模块，直到这些模块容易分析、理解、设计与编码。通过对这些模 块进行分析、设计，然后使用相应的编程语言实现这些模块，再以编程语言所 定义的方式将这些模块组装起来，形成最终的软件系统。例如，面向过程编程 中，将系统分解为完成单一功能的函数，并通过函数之间的调甩完成复杂的功 能，最终形成这个系统。面向对象编程中，通过分析，抽象出一系列具有一定 属性与行为的对象，并通过这些对象之间的协作完成系统的功能。 传统的编程技术倾向于按照功能或行为对软件系统进行分割，这个分割的 结果是实现某一功能的模块，如函数、过程、类等。但在编程实践中，人们认 识到，软件系统中有些行为无法封装在单个的模块中，例如日志记录、事务处 理、对上下文敏感的错误处理、性能优化等等。通常这些功能与行为不实现系 统的业务功能，但辅助这些功能的实现，并散布在实现系统功能的诸多模块中， 从而造成代码的纠结，这使得实现系统功能的模块代码难于阅读、理解、调试、 维护和扩展等，并使得纠结的代码难于复用。如果我们将实现系统业务功能的 模块看作系统的纵向分解单元，那么上述分散在功能模块中的功能与行为就形 成了一种横切的方面( a s p e c t ) ，方面与模块形成了横切( c r o s s c u t t i n g ) ，从 而造成传统的编程技术无法将方面模块化，造成两种代码纠结( t a n g l i n g ) 在 一起。 因此，我们需要一种新的编程思想，对系统中的横切方面( a s p e c t ) 进行处 理，解决由此造成的代码纠结问题，并使a s p e c t 可模块化，促进功能模块与 a s p e c t 彼此的复用。 西南交通大学硕士研究生学位论文第1 5 页 2 2 2a o p 简介 面向方面编程( a s p e c t o r i e n t e dp r o g r 删i n g ，a o p ) 是一种区别于传统 编程技术的新编程思想，最初的概念由g r e g o rk i c z a l e s 在施乐的p a l oa l t o 研究中心领导的一个研究小组于1 9 9 7 年提出。a o p 正是基于方面与模块形成 横切，造成代码纠结这一现象而提出的，并提出了一种新的编程思路来解决这 一问题。之后，a o p 经由几个不同小组的努力在各自的方向上得到了发展，到 目前为止，a o p 仍处于发展阶段n ，。 a o p 的基本思想 如前所述，造成代码纠结的原因在于传统编程技术中，软件系统中实现非 业务功能的代码无法模块化，散布在实现业务功能的代码中造成的。软件系统 的业务功能组成了核心关注点( c o r ec o n c e r n s ) ，也就是软件系统要解决的问 题，而诸如日志记录，事物处理等关注点散布在核心关注点中，就相互形成了 横切关注点( c r o s s c u t t i n gc o n c e r n s ) 形成了方面这概念。 鉴于此，a o p 提出的解决方法是对这两种相互横切的关注点分别编码，使 用传统的编程语言对核心关注点编程，使用面向方面的编程语言对横切关注 点，埠就是方面进行编程。然后使用一种机制将这两种代码自动混合起来，形 成最终的代码。面向方面的编程语言可以是已有编程语言的扩展( a s p e c t j ， a s p e c t c + + ，a s p e c t c ，a s p e c t c # ，a p o s t l e 等) ，或是一种新的语言( c a e s a r ， d 2 a l ，j a s c o 等) 。而将两种代码混合的机制称为织入( w e a v i n g ) ，实现这一 机制的工具称为织入器( w e a v e r ) 。因此，对方面单独编码，并通过适当的织 入机制使两种代码混合，构成了a o p 解决代码纠结问题的基石n ，。 织入机制( w e a v i n g ) 织入是实现a o p 的一个重要机制，织入的实现机制有多种，基本上可以分 为两类，静态织入与动态织入。静态织入是指在业务功能代码中的适当位置， 比如某段代码执行前，或执行后，将方面中的编码插入，从而形成混合的编码。 方面中的编码在程序运行前，已被内联至业务功能代码中，因此，可以优化代 码，使织入产生的开销最小化，最终产生的混合代码，其执行速度接近于使用 0 0 p 方式编写的代码。但是，静态织入无法做到根据运行上下文动态的决定插 入的方面代码，需要动态织入。根据上下文决定调用的方面，先后顺序，增加 或删除一个方面等。 而根据织入的时间，又可以分为三类，编译时、载入时、运行时。编译时 西南交通大学硕士研究生学位论文第1 6 页 织入可以在编译前进行预处理，将两种代码自动混合，将方面中的代码自动插 入到功能模块代码的合适位置；也可在编译后，对编译后的代码进行操作。载 入时织入是在代码载入时j 实现代码的织入；运 亍肘织入则在运行时，根据对 方法的调用执行适当的方面代码以实现织入。以a o p 的j a v a 实现为例，包括 使用反射( r e f l e c t i o n ) ，基于动态代理( d y n a m i cp r o x y ) 或其它机制的拦截 框架，基于元数据( m e t a d a t a ) 的操作，以及类载入时对字节码的操作等。随 着a o p 应用的进一步推广，相信会有更多新的织入方式出现。 2 2 3a o p 术语定义 a o p 术语定义了a o p 各个元素的语义，为a o p 引擎的实现提供标准，同时 以便于更好地理解的a o p 相关概念m ，f ra i i i e s e r v e r 的a o p 引擎支持下列绝大 多数术语： 分散关注( c r o s s c u t t i n gc o n c e r n ) ：在0 0 模型中，虽然大部份的类只 有单一的、特定功能，但它们通常会与其他类有着共同的第二需求。例如，当 线程进入或离开某个方法时，我们可能既要在数据访问层的类中记录日志，又 要在u i 层的类中记录日志。虽然每个类的基本功能截然不同，但用来满足第 二需求的代码却基本相同。 参考( a d v i c e ) ：它是指想要应用到现有模型的附加代码。在本例中， 它是指线程进入或退出某个方法时要运行的日志代码。 切点( p o i n t c u t ) ：这个术语是指应用程序中的一个执行