（计算机应用技术专业论文）支持xml配置的ioc微容器设计.pdf

摘要 降低耦合度一直是软件工程追求的一个目标。耦合度的降低将会提高软件的 复用，但是传统方法无法摆脱类与类之问的依赖，从而引入了反转控制。它通过 容器对类与类之间的依赖进行管理，从而达到降低耦合度的目的。 本文主要对反转控制模式的原理，意义，实现方法进行了研究，并且全面系 统的设计了一个短小精干的轻量级容器。通过j a v a 语言的接口，容器实现了一 个良好的框架用于以后的扩展。同时在j a v a 语言的基础之上，它也拥有一套完 善的异常处理系统。本容器特别针对当前的微容器不能支持x m l 配置的缺陷， 提出一个自己的改进方法。通过对x m l 的支持，可以极大的改善代码的扩展性， 避免了代码中不必要的依赖注入。由于本容器的使用对象是小型企业级应用，所 以它实现了依赖的自解决，减轻了使用者的负担。 本容器的设计通过容器对反转控制的支持，有效的降低了代码之间的依赖， 提高了软件开发的速度与降低维护以及二次开发的难度。本容器即可以单独在工 程中使用，也可以作为大型容器的一部分发挥作用。本容器为使用反转控制模式 的应用提供了有力的工具。 关键词：轻量级容器微容器反转控制依赖注入 a b s t r a c t a ta l lt i m e so n eg o a lo fs o f t w a r ee n g i n e e r i n gi sr e d u c i n gt h ec o u p l i n g w h i c hc a l l i m p r o v et h er e u s a b i l i t yo fs o f t w a r e ，b u tt r a d i t i o n a lm e t h o dc a l l tg e tr i do ft h e d e p e n d e n c ea m o n gc l a s s e s s oi n v e r s i o no fc o n t r o l ( i o c ) i si n t r o d u c e d t h i sm e t h o d m a n a g e st h ed e p e n d e n c ea m o n gc l a s s e st h r o u g ht h ec o n t a i n e r , a n dt h e na c h i e v e st h e g o a lo fr e d u c i n gt h ec o u p l i n g t h i sp a p e rm a i n l ys t u d i e st h ep r i n c i p l e ，m e a n i n ga n di m p l e m e n t a t i o no ft h ei o c p a r e ma n dd e s i g n e dac o m p a c tl i g h t w e i g h tc o n t a i n e rc o m p l e t e l ya n ds y s t e m a t i c a l l y i tp r o v i d e sag o o df r a m e w o r kb yj a v ai n t e r f a c e a tm e a nw h i l ei th a sap e r f e c t e x c e p t i o nh a n d l em e c h a n i s mb a s eo nt h ej a v al a n g u a g e s i n c et h ec u r r e n tm i c r o c o n t a i n e rc a n ts u p p o r tx m lc o n f i g u r a t i o nd e f e c t s ，t h i sp a p e rh a sm a d ei t so w n e n h a n c e m e n tc r e a t i v e l y b ys u p p o r t i n gt h ex m lc o n f i g u r a t i o n ，i tc o u l dg r e a t l y i m p r o v et h es c a l a b i l i t yo ft h ec o d ea n da v o i dt h eu n n e c e s s a r yd e p e n d e n c ei n j e c t i o n b e c a u s et h em i c r oc o n t a i n e ri sd i r e c t e da tas m a l lb u s i n e s sa p p l i c a t i o nl e v e l ，i t a c h i e v e ss e l f - r e s o l v eo nt h er e l i a n c e ，m a k i n gi te a s i e rf o rt h eu s e r t h es i g n i f i c a n c eo ft h ec o n t a i n e rd e s i g ns u p p o r t i n gt h ei n v e r s i o no fc o n t r o li st o r e d u c et h e d e p e n d e n c eb e t w e e nc o d e s ，a n di m p r o v et h es p e e do f s o f t w a r e d e v e l o p m e n ta n dm a i n t e n a n c e ，a n dm a k es e c o n d a r yd e v e l o p m e n te a s i e r t h i s c o n t a i n e rd o e sn o to n l yw o r ka l o n ei nap r o j e c tb u ta l s oc a l lb eap a r to fah u g e c o n t a i n e r i tp r o v i d e sap o w e r f u lt o o lf o ra p p l i c a t i o nw h i c hu s e st h ei o cp a t t e r n k e yw o r d s ：l i g h t w e i g h tc o n t a i n e r , m i c r oc o n t a i n e r , i o c ( i n v e r s i o no f c o n t r 0 1 ) ，d i ( d e p e n d e n c ei n j e c t i o n ) 独创性声明 本人卢呐所： 父i i j 7 1 “ i 比义比小人“：哥帅指导j 。迸 j ：的研究1 f 们。r l 愀i t - ：j 的 石j f ：究成果，除了文一寺别力以标注和致酣之处乡i ，论文中不包含其他人已经发表 或撰：写过的研究成粜，也卅i 包含为获得叁盗盘堂或其他教育机构的学位或证 n j 使- t jj 过r t , j 利料。：我。川j i ：f i - f l , , j i 礼基列小研究所做的ft f i | 贡献均已在论文中 作了 刃确的说f j j i ：表刁：j 谢意。 学位论文作者签名：拯亿签字同期：叼年易月b 同 学位论文版权使用授权书 本学1 辽沦文作者完全了解苤盗盘堂有关保留、使用学位论文的规定。 特授权基盗盘鲎司。以将学位论文的全部或部分内容编入有关数掘库进行检 索，新：采h 影印、缩印塑戈= _ i 捌i 等复制予段保存、汇编以供奄阅和借阅。同意学校 r t , j 幽家平r 关部i 、j 或机构送变论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 学位沦义作者签积：熟1 乞 导帅签红： 签字闩期：砷年 易月 1 签字r 期：吱。呷年多月哆h 第南绪论 1 1 课题的背景和意义 第一童绪论 随着企业信息化建设的不断深入，食业应用开发的需求有了很大的增k 。同 叫琐h 的工作量也越来越夫以往作坊彤式的生产方式已经无法满足企业级的衙 求。这样必然产牛了软件的团队开发。由于一个项目经常是由不同团队开发，有 刚甚至是由不同公司开发的，所以对这些模块之问的整台便成为丁一个问题。与 此同时，由于客户的原因或者客户与开发人员之问淘通的问题使一个项h 的很多 时问往往要不停的改变需求。所有的这一切都要求开发的软件具有较低的耦台 度，f h 是如何降低这种耦台度呢? 经过很多专家研究，i o c ( 1 n v c r s i o no f c o n t r 0 1 ) 可以有效的降低娄与粪之闸的耦台度降低模块组台过程中遇到的阻力，减轩* ： 隶娈化对软件开发带来的巨大影响【1 j 。l o c 模式虽然是不局限语言不局限使刚背 景的，仇是现夸辛要麻用领域是j 2 e e 。除此之外在很多非证业级应用方面成加 l o c 来降低耦合，比如某些无线通讯研究川和一一些非线性编程川方面都有麻用。 与此同叫根多大公司的产品也采用了i o c 的设计模式降低耦合，比如b e a 公 司的b e e h i v e i 。 由各个不同团队开发的软件就好像下面圈1 一l 的u 盘与移动硬盘。当它们与 我们的笔记本进行连接的时候需要一个统一的接口这个就是我们的u s b 接口。 我们的l o c 容器就好像是这个u s b 接口的控制器。我们不同组件开发的软件有 着不同的内部构造，如果没有一个统一的接口整合将会很旋。在不使用l o c 模式 的程序中这个将外围组件与丰体组件结合的将会由组件丰体来管斟，而如粜使用 图l i 矧什桨台示意图 。； 第一章绪论 l o c 容器，容器将会接管这个工作。实现组件的无缝连接的同时也提高了软件的 复用程度。在这个容器接管的时候，由容器控制程序之间的关系，而非传统实现 中，由程序代码直接操控。这也就是所谓“控制反转”的概念所在：控制权由应 用代码中转到了外部容器，控制权的转移，是所谓反转。 目前流行的i o c 微容器主要存在以下几个问题：第一，配置麻烦。由于有些 容器需要同时兼顾大型企业级应用与小型企业级应用，所以没有做到专注，无法 做到兼顾。第二，一些小型的容器虽然具有容量小的优点，但是并不支持流行的 x m l 配置的功能。这样的话会给l o c 容器的优点带来一定的退化。比如任何注 入的代码都要手动编写，需求变化后还是要重新编译代码，虽然减少了代码重编 译的数量，但是还是无法改变重编译的事实。因此很有必要加入对x m l 配置文 件的支持。 1 2 本文的主要工作 本文的主要工作就是通过对i o c 理论的深入研究，完成一个支持i o c 模式的 容器，同时特别添加了支持x m l 配置的功能。主要研究问题包括i o c 的注入机 制，注入方式，方式的分类。此容器与面向大型应用开发的容器相比，还具有自 动依赖解决的功能。此容器的主要面向对象是小型企业级应用，同时也可以作为 大型容器的一个组成部分，发挥作用。在编写容器的过程中主要完成的工作有： - 设计一个良好的框架 一在构架的基础上完成一个完整的容器实现。 一构建一个良好的异常处理方式。 编写适当数量的测试代码。 除了编写容器外，本文还对使用容器与不使用容器的一个j 2 e e 工程进行了 简单的比较。 1 3 全文安排 论文的各章节安排如下： 第一章介绍i o c 微容器设计的应用背景，分析现有的解决方案，提出以支持 x m l 为特色的方案，并简述了自己所做的主要工作与文章主要安排。 第二章对i o c 容器产生的背景知识做简要的介绍。在各个方面上对微容器与 相对性的e j b 进行了详细的比较，得出它们各自的优缺点。 第三章主要详细描述了如何设计编写一个完整的l o c 容器，从总体上进行了 第一章绪论 详细的讲解，并且对其中的重要部分用代码进行了说明。同时也对各种实现l o c 方式进行了比较与选择。 第四章主要讲述了容器的功能测试，并且对应用所做容器进行的一个开发进 行了简单的讲解。 第五章对目前所做的工作进行了总结并指出今后的工作方向。 第_ 二章l o c 容器背景知识概述 第二章i o c 容器背景知识概述 2 1j 2 e e 的相关知识 2 1 1j 2 e e 的由来与优势 企业级应用程序框架经历了漫长的演进过程。第一代企业应用程序由集中的 大型机应用程序组成。在上个世纪8 0 年代末到9 0 年代初，大多数企业应用程序 都应用两层框架，这两层框架分别是客户端、服务器。然后随着发展，企业级应 用逐渐过渡到三层构架，然后演变成基于w e b 的构架。这一阶段i n t e m e t 的广泛 应用对这个过渡与演变起到了巨大的推动作用。目前j 2 e e 应用程序框架代表了 最新的发展情况。j 2 e e 全面支持二层和三层应用程序，以及基于w e b 的应用程 序和w e b 应用程序【5 j 。 j 2 e e 是j a v a2e n t e r p r i s ee d i t i o n 的缩写。j 2 e e 是使用j a v a 语言技术开发企 业级应用的一种事实上的工业标准。它是j a v a 技术不断适应企业级应用需求的 产物。在j a v a 的初级版本中并没有j 2 e e ，它是j a v a 2 平台推出以后才出现的。 从j a v a 2 ，也就是j a v a l 4 版本后，j a v a 把自己分为了三个版本，分别是：j 2 m e ( j a v a 2m i c r oe d i t i o n ) ，这个版本适用于小型设备和智能卡；j 2 s e ( j a v a2s t a n d a r d e d i t i o n ) ，这个版本应用于桌面系统：j 2 e e ( j a v a2e n t e r p r i s ee d i t i o n ) ，这个版本 主要是应用于企业级的应用。j 2 e e 平台本质上是一个分布式的服务器应用程序 设计环境，它提供了：宿主应用的一个运行基础框架环境和一套用来创建应用的 j a v a 扩展a p i 5 1 。 现今，很多的开发者都希望能够写出企业级的分布式的应用程序，所以在速 度、安全性、服务器的稳定性上面都有很高的要求。花更少的时问，更少的成本， 开发更加高速的程序是软件行业追求的目标【6 】。为了能够减低费用和开发的步 骤，j 2 e e 平台提供了基于组件的策略用来设计，开发，编译，配置企业级的应 用程序。j 2 e e 平台提供了多种的分布式程序模式 _ 7 1 ，可重用的组件，统一的安 全模型，灵活的事务控制，并且w e b 服务支持基于开放的标准和协议的x m l 格 式【8 】。我们应用j 2 e e 不仅可以缩短软件开发环境，而且一个整套的应用可以由 不同的公司、部门负责，任何符合规范设计的产品，都可以替换具有相同功能的 部分。这样实现了开发的模块化。因此是不会受到任何一个卖主的产品和a p i 的影响，卖主和消费者更喜欢这种能够自由的选择组件，因为可以更好的理解商 4 第_ 章i o c 容器背景知识概述 务和技术上的需求。总结起来，j 2 e e 优点主要有以下几点： 第一，完整的w e b 服务支持。j 2 e e 提供了一个基本的框架，以便在j a v a 平 台上开发和部署w e b 服务。j a v aa p if o rx m l b a s e dr p c ( j a x r p c ) 使得j a v a 技 术开发人员能够开发基于s o a p 的、能够互操作并且可移植的w e b 服务。开发 人员可以使用标准的j a x r p c 编程模型来开发基于s o a p 的w e b 服务客户端和 端点。w e b 服务端点是使用w e b 服务描述语言( w s d l ) 文档来描述的。j a x r p c 使得j a x r p c 客户端能够调用跨异构平台上开发的w e b 服务。同样，j a x r p c w e b 服务端点可以由异构客户端调用【9 1 。 第二，更加快速的解决方案和更快的面市时间。j 2 e e 平台使用“容器”来 简化开发。j 2 e e 容器提供了业务逻辑与资源和生命周期管理的分离，这表明开 发人员可以将重点放在编写业务逻辑( 它们的增值) 上，而不是放在企业基础结 构上。例如，e n t e r p r i s ej a v a b e a n s ( e j b ) 容器( 由j 2 e e 供应商实现) 处理了分 布式通信、线程处理、缩放、事务管理等。与此类似，j a v as e r v l e t s 简化了w e b 开发，因为它在w e b 容器中提供了针对组件、通信和会话管理的基础结构，而 该容器又与w e b 服务器集成。 第三，自由的选择。j 2 e e 是一组许多供应商都可以实现的标准。供应商可 以自由地完成实现，但在标准或a p i 上却不能自由完成。s u n 为j 2 e e 持证人提 供了综合的j 2 e ec o m p a t i b i l i t yt e s ts u i t e ( c t s ) 。j 2 e ec t s 有助于在应用程序供 应商之问保证兼容性，从而保证了针对j 2 e e 平台编写的应用程序和组件的可移 植性。j 2 e e 平台为服务器带来了“编写_ 次，随处运行”( w r i t eo n c e 。r u n a n y w h e r e ) 的能力。 第四，简化的连接。j 2 e e 技术使得可以容易地连接已经拥有的应用程序和 系统，并将这些能力带到了w e b 、手机和设备。j 2 e e 提供了j a v am e s s a g es e r v i c e ， 以便以采用松耦合、异步的方式来集成不同的应用程序。j 2 e e 也提供了对 c o r b a 支持，以便通过远程方法调用来紧密地链接系统。j 2 e e 平台还具有 j 2 e ec o n n e c t o r s ，用于链接企业信息系统，比如e r p 系统、打包的财务应用程 序和c r m 应用程序。 通过提供具有如上特征的平台，j 2 e e 平台可帮助软件开发公司缩减开发成 本与速度，同时免去了针对企业软件要求的单一源码【1 0 】。 2 1 2e j b 的相关知识 e j b ，即e n t e r p r i s ej a v a b e a n s ，是s u n 推出的运行在容器中的服务器端组件， 用于实现业务逻辑。e j b 组件类似j a v a b e a n 组件，开发人员仍以单线程模型编 写e j b ，不必了解低层次的事务和状态管理的细节、多线程、资源共享和其它复 第二章l o c 容器背景知识概述 杂的低级a p i ，这些功能都将由e j b 容器实现，大大简化了分布式对象的开发、 部署和访问。并且，e j b 应用程序也遵循j a v a 语言的“一次编写，随处运行”的原 则。e j b 组件可以只开发一次，然后在多个平台上部署。e j b 与其它j 2 e e 的技 术一起，大大增强了j a v a 的能力，并推动了j a v a 在企业级应用程序的应用。从 企业应用多层结构的角度，e j b 是商业逻辑层的构件技术。与j a v a b e a n s 不同， 它提供了事务处理的能力，自从三层结构提出，中问层，也就是商业逻辑层，是 处理事务的核心。由于从数据存储层分离，它就取代了存储进程的大部分地位。 从分布式计算的角度，e j b 像c o r b a 一样，提供了分布式技术的基础，提供了 对象之间的通讯手段。从i n t e r n e t 技术应用的角度，e j b 和s e r v l e t ，j s p 一起 成为新一代应用服务器的技术标准。e j b 中的b e a n 可以分为会话b e a n 和实体 b e a n ，前者维护会话，后者处理事务。现在，s e r v l e t 负责与客户端通信，访 问e j b ，并把结果通过j s r 产生页面传回客户端，成为开发的新潮流1 。 e j b 对应用程序的开发者和客户都有很多的好处，由于本文主要讨论开发问 题，所以主要讲解对于开发者的好处。 第一，简单性。e j b 的框架可以使我们更容易的开发企业级应用程序。开发 者不用考虑很多系统级的问题，比如：事务、多线程、安全性、安全协议j 分布 式计算等。这些复杂的系统级问题都被e j b 的框架结构屏蔽掉了，开发者可以 专注于特定领域的应用程序的业务逻辑。 第二，组件可重用性。组件的重用一直是软件开发追求的目标之一，这样可 以有效的提高工作效率，缩短软件开发周期。e j b 应用程序是由企业b e a n 组成 的。每个b e a n 都是一个可重用的组件。 第三，分布式部署。e j b 的框架使应用程序可以很容易的按照分布式部署到 一个网络的多个节点服务器上。e j b 很好的剥离了相关性，b e a n 的开发者不需要 知道这个b e a n 是否要在不同的应用服务器上运行。分散关注可以使开发人员专 注某一项工作，这样减少了当前工作的出错几率，很好的提高了产品质量。 第四，应用的可移植性。只要满足j 2 e e 的规范，e j b 可以部署到任何一台 服务器上。这意味着任何的e j b 应用程序不用与特定的服务器强制连接在一起， 不局限于特定应用服务器。他们所做的就是选择满足他们需求的最好的服务器。 第五，业务逻辑与表示逻辑分离。企业b e a n 经常封装一个业务逻辑或者业 务实体，使它独立于表示逻辑。业务人员只关心传递给w e b 页面的数据，使他 们的关注点集中在业务。对于输出格式，表示逻辑都不需要开发人员操心。而且 任何非业务需求的变化都不会影响业务代码的修改。 第六，可以与非j a v a 系统进行集成。相关的j 2 e ea p i ( 诸如j 2 e e 连接器规 范和j m s 规范) 和j 2 e ew e b 服务技术( 诸如j a x r p c j a v aa p if o r 6 第一章l o c 容器背景知识概述 x m l b a s e dl u c ) ，使我们可以使用一种标准的方法，将企业b e a n 应用程序与各 种非j a v a 应用程序( 诸如e r p 系统或者大型机应用程序) 集成1 5 1 。 我们上面罗列了一些e j b 的优点，但是虽然e j b 宣称具有以上的优点，e j b 的目前状况并没有完全做到，比如e j b 的移植性问题。但我们也要考虑到e j b 的发展是一个渐进的状态，这些优点既然都在考虑之内，相信随着新版本的出现 这些优点都会一定程度上的体现。 2 1 3 微容器的起源与现状 在j 2 e e 应用的设计过程中，e j b 经常被当作j 2 e e 的核心，然而e j b 只不 过是j 2 e e 提供的选择之一。在理论上它成功的解决了某些难题，但是在许多现 实应用中只具有很小的价值。只有在业务明确需求分布式体系结构，远程化协议 为r m i i i o p 时，e j b 才会体现出它的价值。所谓微容器是相对于e j b 而言的， e j b 虽然提供了一堆重量级的服务，如j t a ，j m s 等，但是这些服务都会造成部 署复杂、运行缓慢、难于测试等问题。特别是在当今测试驱动开发大行其道的今 天，难于测试的东西都被贴上了低质量的标签。微容器正是在这种需求驱动下提 出的。 在j a v a 语言中，容器就是底层的、与支撑平台相关的、对组件进行功能化 支持的接口。微容器的主要功能有如下几个方面： 第一，维护组件的周期。即容器中注册的组件初始化和资源的释放都是通过 容器来控制的。比如在此容器中s t a r t a b l e 和d e c o n s t r u c t a b l e 中的接口。任何实现 这两个接口的组件，在注册到容器后它的生命周期方法都会在适当的时候被调 用。 第二，对组件之间的依赖进行解析。本容器在组件注入容器后就会对各个组 件进行分析，找出它们之问的依赖关系。 第三，提供简单的配置组件方式。如s p r i n g 通过x m l 配置文件将程序中的 所有组件以b e a n 的形式定义并配置在一起【1 2 】。本容器的配置方式则是支持j a v a 代码与x m l 配置两种方式。 第四，提供查找被管理对象的机制。注册到容器中的组件可以通过查找会的 对象【j 。 此外，容器还提供一些增值服务，主要包括：企业级服务、线程服务、对象 池、集群服务、管理、远程服务、暴露远程服务、消费远程服务、可定制性和扩 展性等等【川。 因为在微容器中，容器对应用代码没有丝毫的侵入性，应用代码不需要实现 任何容器的接口，只在需要使用容器的地方调用容器的a p i ，用户可以自己定义 第二章i o c 容器背景知识概述 服务，所以微容器的开发得到了快速的发展。比较有名的容器有：s p r i n g ”】和 p i c o c o n t a i n e r t l6 1 。 s p r i n g 项目是一个开源项目，启动于2 0 0 3 年2 月。其中基础的东西都来自 于r o dj o h n s o n2 0 0 2 年末写的e x p e r to n e 0 1 1 o n ej 2 e ed e s i g na n dd e v e l o p m e n t 一书。s p r i n g 框架对设值方法依赖注入和构造子依赖注入都提供了完善的支持 【1 7 】。s p r i n g 除了一般容器所拥有的功能之外还有许多特性： 第一，依赖检查。s p r i n g 可以自己检查是否已经装配了所有的j a v a b e a n 属 性。对象的依赖关系和简单属性可以分开检查。 第二，自动装配。s p r i n g 可以在当前容器中自动挑选满足依赖关系的对象。 并通过j a v a b e a n 属性将其提供给需要的对象。 第三，支持集合。s p r i n g 可以自动装配l i s t 、m a p 以及其它使用的j a v a 集合 对象类型。同时，s p r i n g 也支持集合类型的任意嵌套，例如在m a p 中包含一个 l i s t 等。集合中包含的可以是简单类型，也可以是同一个容器中的其它对象的引 用。 另一个比较流行的微容器就是p i c o c o n t a i n e r 。这是一个极度轻量级的容器， 侧重于构造子注入方式，实际上正是它开创了这种注入方式。与s p r i n g 相比较 它并不强调将依赖关系抽取到代码之外，比如通过x m l 来配置依赖关系。它根 据受管理的构造子定义去判断依赖关系。p i c o c o n t a i n e r 也提供了设值注入方式， 只不过没有s p r i n g 那样提供了很多附加的功能。 总体来说随着开源社区的兴旺发达，某些微容器的项目得到了前所未有的发 展。不仅对于本文主要实现的i o c 功能，还包括很多其它的功能比如a o p ( a s p e c t o r i e n t e dp r o g r a m m i n g ) 都有了很好的支矧1 8 】。例如：p i c o c o n t a i n e r 的姊妹项目 n a n o c o n t a i n e r l l 9 j 在p i c o c o n t a i n e r 的基础上实现了对a o p 的支持。而且开源社区 的勇于挑战与实现新思路新想法的精神，为微容器的发展提供了良好的支持。但 是虽然容器的构造、功能不尽相同，但是从受管理的对象的角度来说，容器没有 什么本质的区别。 2 1 4 微容器与e j b 的比较 e j b 的原意是简化企业级应用的开发。也就是说e j b 希望让应用开发人员能 够将注意力集中于他们的问题领域和编写业务逻辑，而不是去关注系统级的问 题。很不幸的是，这些设想都没有实现。随着e j b 规范变得越来越复杂，开发 应用服务器也变得越来越缺乏经济上的吸引力，应用服务器领域的竞争逐渐减少 了。另一方面，开发工具对e j b 的支持有所改进，但是仍然让人失望。开发一 个e j b 仍然很冈难，比开发一个j a v a 类或者j 2 e ew e b 组件要网难的多。每一个 第_ 二章i o c 容器背景知识概述 应用服务程序都要一个基础框架。在没有轻量级容器以前，由于没有更好的方法 管理业务对象，所以在构建大规模的j 2 e e 应用时一直不能脱离e j b t 2 0 j 。而现在 由于出现了轻量级的容器，使得抛弃e j b 成为可能。 e j b 主要存在的丰要问题主要有以下几点： 第一，使用e j b 必须有e j b 容器，这样就绑定了容器。这样的绑定会带来 了几个方面的困难。首先，选择e j b 限制了我们对应用服务器的选择。我们将 不能使用像t o m c a t 这样的开源社区的精品。而且e j b 的服务器的费用也很高， 提高了开发成本。其次，用大炮打苍蝇。e j b 是一个复杂的框架，它支持了很多 功能，但是在实际生活中我们的某一个工程中并没有对每个功能都有要求，这就 造成了一种极大的浪费。再次，e j b 的a p i 对业务对象进行了侵入。a p i 对对象 的侵入直接影响了复用。最后，我们不能在e j b 容器之外复用e j b 的业务逻辑【5 】。 第二，e j b 有复杂的部署配置文件。在j 2 e e 的开发中很多的部署都是通过 x m l 文件来配置的。这种配置文件很容易出错，看看在j 2 e e 开发者论坛中请教 问题的时候很多时候都是由于开发者没有正确的配置x m l 。而e j b 的部署描述 文件更是冗长、不直观，几乎不可能手工编写。标准的e j b - j a r x m l 部署描述文件 将一些非常重要的信息( 例如指定b e a n 的j n d l 名称等) 留给容器开发商定制， 所以我们总需要一个额外的、跟厂商相关的描述文件，例如w e b l o g i c 的 w e b l o g i c e j b - j a r x m l 。这样也就破坏了应用在不同服务器之间的移植性。 第三，难于测试。因为e j b 的应用都要运行在e j b 容器中，所以如果想对 e j b 应用进行测试，这将是很冈难的。e j b 的应用都缺乏有效的单元测试。e j b 这种框架过度依赖容器，s l s b ( s t a t e l e s ss e s s i o nb e a n ) 很难做单元测试；而e n t i t y b e a n 根本没有办法做单元测试，因为它们都是抽象类，由容器负责在运行时提 供具体的子类。因为难于测试很多系统架构师都将e n t i t y b e a n 设计成为哑数据， 即只有s e t t e r 和g e t t e r 方法，不含任何行为的对象。这样e j b 给我们的面向对象 的编程制造了很多的束缚。而轻量级容器架构可以让我们使用普通的j a v a 接口 来抽象业务逻辑。我们可以使用一种透明的持久化方法，比如o r m 或者j d o ， 这样持久对象就不会与e j b 容器或者特定的持久化框架绑定。 第四，难于移植。e j b 曾经承诺过，不需要重新编译或者修改源代码，即所 谓的一次编写到处执行。但实际上e j b 没有兑现这个承诺，在实际中几乎没有 什么真正有用的e j b 应用可以很容易的在不同的应用服务器问移植。例如上面 提到的某些配置文件就是一个很好的例子。 第五，过多的类。e j b 规定实现一个s e s s i o nb e a n 需要三个j a v a 的源文件。 这三个文件分别实现h o m e 接口，实现组件接口，还有b e a n 的实现类。此外e j b 拥有一个复杂的类加载机制，e j b 通常不与w e b 容器使用同一个类加载器。而类 9 第二章i o c 容器背景知识概述 加载器越多，造成问题的概率也就越大，在不同应用服务器之问的行为差异也就 越大。 而同时微容器又具有以下几个优势： 第一，提高代码的复用。前面提到e j b 要实现一些接口，而且它们应用了 一些e j b 特有的a p i ，这样的程序只能限定在e j b 容器中运行。因此我们的代 码的顺利运行就有了一个前提，限制了一个特定的环境，从复用的角度来看这样 是很不科学的。 第二，更好的贯彻面向对象的原则。之所以微容器比e j b 更好的贯彻了面 向对象的原则，这主要是因为e j b 组件通常不是真正的面向对象。这个原则上 的缺陷主要源于e j b 组件模型的特性。在e j b 中，所有的e j b 的粒度都是比较 粗的，这给平常的面向对象的设计习惯增加了额外的约束。同时e j b 组件模型 也不支持继承，仅允许e j b 实现类的继承。而微容器对于我们的限制很少，我 们可以尽情的展现我们面向对象的思想。 第三，更好的测试。e j b 容器是很复杂的，启动需要很长时问，如果我们一 边开发一边测试，测试的大量的时间都会花费在启动容器上面。而e j b 应用又 无法离开容器进行单独测试。这就造成了无法进行详细的测试。采用微容器的应 用可以脱离容器，比如利用j u n i t 进行测试，使得软件的可靠性得到了极大的提 高。 第四，更低的侵入性。前面已经提到过，e j b 组件要实现特定的接口，来完 成远程调用等功能。但是这样就限制了灵活性，意味着离开e j b 后，代码需要 进行一定的调整。而微容器就没有这些要求。对于运行在其中的组件，它没有任 何要求。 第五，更好的选择性。e j b 是一个重量级的容器。它提供服务的方式是“要 么全有，要么全无”。这样对于些仅仅需要部分功能的应用，便支付了很多没 有必要的开销。他们不得不花费更多的资金，维护更加庞大的结构。而微容器则 采取了一种自助式的服务，通常一个全面的容器，例如：s p r i n g ，它提供了很多 功能，如：a o p ，i o c ，事务管理，持久化等等【2 。这些功能对应相应的模块， 对于一些小项目，由于对功能要求不多，可以起到很好的“瘦身”作用，也很好 的降低了成本。 综上所述，微容器可以很好的弥补e j b 的缺陷，所以在轻量级应用中用微 容器部分取代e j b 已经成为一种趋势。 1 0 第一章i o c 容器背景知识概述 2 2i o c 与依赖的关系 所谓依赖就是指两个对象之间个对象的改动会影响另外一个对象的行为。 例如，一个类p e r s o n ，另一个类c a r ，如果p e r s o n 的某个方法d r i v e ，需要引用 c a r ，则称p e r s o n 类依赖于c a r 类，延伸到对象c a r ，这种依赖关系依然成立。 我们通过这个d r i v e 方法的实现来说明，假定代码如下： p u b l i cp e r s o n p u b l i cv o i dd r i v e ( ) c a rc a r = t l e wc a r ( ”t o y o t a ”) ； c a r 挂档( ) ； c a r 踩油f 7 0 ； c a r 打方i 占jo ； ) ) 这其中的依赖关系，就导致了对象m e n 需要负责对象c a r 的创建，甚至是整 个生命周期的管理，而这样显然会带来耦合度高，不易维护等缺点，比如说要让 这个男孩驾驶一辆a u d i ，则还需要修改类p e r s o n 的代码。 因此在j a v a 的设计理论中就提出了一条非常著名的原则，依赖倒转原则 ( d e p e n d e n c ei n v e r s i o n ) ，其核心思想就是要将这种具体类之问的依赖，尽量转 换成抽象依赖，也就是说类p e r s o n 应该依赖于抽象类i c a r ( 其实是一个接口) ， 而不是具体的类c a r 。著名的好莱坞原则：“不要来找我，我会找你的。”【2 2 1 就 是对它的最好的解释。而j a v a 提供了强大的针对接口编程的能力，给我们提供 了很多便利【2 3 】。特别是g o f ( g a n go f f o u r ) 设计模式中，提供了一种思维编程方式： 接口驱动，更是在理论上给我们提供了支持2 4 1 。 这个依赖倒转原则在设计模式也体现得非常多，比如说工厂模式和构建模式 【2 5 】，控制反转i o c 其实也是实现这个原则的一种设计模式。i o c 是英文i n v e r s i o n o f c o n t r o l 的缩写，中文为反转控制。我们一直追求软件耦合度的降低。只有简 单的对象才能独立的工作，大多数的业务对象都有依赖关系，比如与其它业务对 象、与数据访问对象、与各种资源之问都存在着依赖关系。以前对象需要查找其 它的受管对象和资源，而受管对象的改变便会引起管理者行为的改变【2 6 1 。而现在 我们可以应用反转控制和依赖注入。在一般的框架中，控制反转是一个很重要的 概念，它是体现了上面说过的好莱坞原则。控制反转将某个类型的定义与它的实 现通过一些配置信息分离开，在需要该类型实例时，可以通过配置信息来实例化， 第_ 章i o c 容器背景知识概述 而不是直接编码【2 7 】。 还是以上文的m e n 与c a r 为例，其核心就是要将m e n 依赖的对象c a r 注入到 m e n 中去，而无需m e n 自己去引用c a r ，这个注入的过程，通常是由一个控制程 序来完成的，无需对象去关心，举例如下： p u b l i cp e r s o n p r i v a t ei c a rc a r ； p u b l i cp e r s o n ( i c a ro n e c a r ) c a r = o n e c a r ； p u b l i cv o i dd r i v e ( ) c a r 挂档( ) ； c a r 踩油门( ) ； c a r 打方向o ； ) 这个时候，进行注入并且调用的过程，就很简单了，如下： c a rc a r = n e wc a r ( ) ； p e r s o nm e n - - n e wp e r s o n ( c a r ) ； m e n d r i v e ( ) ； 注：这里我们假定，c a r 类是i c a r 接口类的一个具体实现。 这个例子就演示一个最简单的注入方式的例子。如下： p u b l i cp e r s o n p r i v a t ei c a rc a r ； p u b l i cp e r s o n ( ) ) p u b l i cv o i dd r i v e ( ) c a r 挂档( ) ； c a r 踩油门( ) ； c a r 打方向o ； ) p u b l i ci c a rg e t c a r ( ) r e t u r nt h i s c a r ； ) p u b l i cv o i ds e t c a r ( i c a rs o m e c a r ) 第_ 章l o c 容器背景知识概述 c a l = s o m e c a t ， ) 这个时候，进行注入并且调用的过程，就变成如下所示： c a rc a r = n e wc a r ( ) ； p e r s o nm e n - - n e wp e r s o n ( ) ； m e n s e t c a r ( c a r ) ； m e n d r i v e ( ) ； 这样即使以后的软件需求变为要让这个男孩驾驶一辆a u d i ，也不需要修改 类p e r s o n 的代码，有效的提高了扩展性。 2 3i o c 的分类 控制反转的类型可以分为两类，一类是依赖查找，一类是依赖注入【2 8 1 。在产 生的先后顺序上依赖查找比较早，j a v a 程序员一般对它都很熟悉。而依赖注入就 比较新，看上去与以前的习惯不同，而且方法还没有定型。在功能上可以说依赖 注入拥有更强的弹性，而且更加有用例。 2 3 1 依赖查找 依赖查找主要分为两类：依赖拖拽与上下文配置依赖查找。 依赖拖拽是种历史最悠久，大家最熟悉的方法。依赖关系是通过一个“登 记处”得到的。使用过e j b 的程序员基本都是用过这种方式。这种通过“登记” 的方法不止局限于i o c ，从“登记”处得到依赖关系的j n d i 查找也用到了这种 方法。下面是在s p r i n g 容器中应用拖拽的典型代码： p u b l i cs t a t i cv o i dm a i n ( s t r i n g a r g s ) g e tb e a nf a c t o r y b e a n f a c t o r yf a c t o r y = g e t b e a n f a c t o r y 0 ； m e s s a g e r e n d e r e rm r = ( m e s s a g e r e n d e r e r ) f a c t o r y g e t b e a n ( “r e n d e r e r ) ； m r r e n d e r 0 ； 上下文配置依赖查找与上面说到的依赖拖拽差不多，某些地方与它相同。唯 一不同的地方是上下文配置依赖查找是在容器管理的资源中进行的，而不是从一 个集中的“登记”处得到的。上下文配置依赖查找的工作方式如下面代码： p u b l i ci n t e r f a c em a n a g e d c o m p o n e n t 1 3 第二章l o c 容器背景知识概述 p u b l i cv o i dp e r f o r m l o o k u p ( c o n t a i n e rc o n t a i n e r ) ) 从上面的代码我们可以看出来，组件实现一个接口。通