开发框架的选择.docx

《开发框架的选择.docx》由会员分享，可在线阅读，更多相关《开发框架的选择.docx（32页珍藏版）》请在三一办公上搜索。

1、软件开发框架的运用和选择如何在企业业务迅猛发展、应用需求不断扩大、市场竞争日趋激烈、业务整 合难度不断加大的基础上，采用灵活、先进的设计理念及结合开放式的系统软硬 件平台，在确保业务系统安全、高效、可靠的基础上，构建一个完全满足企业信 息化要求，同时在面向、事务调度、系统配置、业务拓展、统计分析方面表现优 异的企业应用，是企业信息化中必须面对的重要问题。由于软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知 识、内容、问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完 成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是 成熟，稳健的，它可以处理系统的很

2、多细节问题，比如，事物处理、安全性、数 据流控制等问题。还有，框架一般都经过很多人使用，所以结构很好，所以扩展 性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。声明：本文是将网络上比较优秀的文章进行了整理和组合，旨在部门内部进 行讨论，不要进行传播，以免引起不必要的争议。1、需要说明的几个概念人们总是偏爱炒作概念。一个表达方式，如果听起来足够响亮，写在纸上能 够吸引眼球，那就会变成很多人的新宠。但同样是这些概念，经过太多人的传递、 消费之后，原本的含义反而像硬币上的图案一样被磨损殆尽：几乎没有人知道这 些说法到底是指什么了。在业界，“平台（）”、“框架（）”、“构架（）”等

3、等就是 这种人见人爱的概念。几乎每个厂商都愿意请来其中的一位、甚至多位为自己推 销。久而久之，这些说法似乎适用于各个领域、各个层面：所有的软件系统都是 “平台”，所有的开发者都在沉迷于独有的“框架”。原本有确切意义的“好词” 经过这一番争夺和滥用，也只能衰减为所谓的心，供市场营销人士们玩味了。（理 解企业应用框架选择自的）1.1框架软件业圣经设计模式对框架有如下定义：“（一个框架，就是一组相互协作的类；对于特定的一类软件，框架构成了一种可重用的 设计）”。这个定义虽然主要着眼于面向对象的软件开发，但已经基本上给出了这 个词的核心含义：框架是软件系统的设计、开发过程中的一个概念，它强调对已 完成

4、的设计、代码的重复使用，并且，一个框架主要适用于实现某一特定类型的 软件系统。为了更好地说明框架是什么，也许还应该看看框架不是什么。框架不是现成可用的应用系统。它仍是一个半成品，等待后来者做“二 次开发”，实现为具体的应用系统。框架不是“平台”。后者的概念更加浮泛和模糊一一人们说的一个平台， 可以是一种操作系统，一种应用服务器，一种数据库软件，一种通信中 间件等等，因此“平台”几乎成了所有系统软件的统称。在平台的大家 族中，框架的概念可能与近来人们常说的“应用平台”最为接近，但平 台主要指提供特定服务的系统软件，而框架则更侧重于设计、开发过程， 或者可以说，框架通过调用平台提供的服务而起作用。

5、框架不是工具包（）类库（）。目前流行的很多框架中，就包括了大量 的类库和，但是调用并不就是在使用框架开发。仅仅使用时，开发者完 成系统的主体部分，并不时地调用类库实现特定任务。而框架构成了通 用的、具有一般性的系统主体部分，“二次开发者”只是像做填空题一 样，根据具体业务，完成特定应用系统中与众不同特殊的部分。框架不是构架（）。构架确定了系统整体结构、层次划分、不同部分之 间的协作等设计考虑。框架比构架更具体，更偏重于技术实现。确定框 架后，构架也随之确定，而对于同一种构架（比如开发中的），可以通 过多种框架（比如 或）实现。（理解企业应用框架 选择自 的）如何最大程度地萃取不同企业应用系统的

6、共性，重复使用已经完成的设计和 代码，对企业应用系统中典型场景给出最佳解决方案一一这是一个“一般性”的 问题；如何让一个早先完成的软件产品贴切地适应极为多变、复杂的企业需求一 这是一个“特殊性”的问题。作为对这一组冲突的一种解决方案，不少厂商推 出了自己的企业应用框架。这些框架往往是从大量的委托项目开发中精选出的系 统“不变项”，因此具有很强的普适性和实用性。目前，主流企业应用框架中大都包含对以下问题的现成解决方案： 持久性（）：实现数据存储、处理，数据与对象映射，数据缓存（）。 事务（）：确保一组关联操作正常、完整的执行。 安全性（）：保证系统的通信安全、数据安全。 负载均衡（）：在大量并发

7、访问时，保持系统可用。 监控（）：监控系统运行状况，设置系统参数。 日志（）：记录系统运行情况和异常，记录特定用户操作。 应用集成（）：与其他系统、应用程序集成。 认证权限组织角色管理（）：管理系统用户、组织职权结构，限制特 定用户对特定功能、特定数据的访问。 业务模型（）：管理系统中业务对象的属性、字段。 业务逻辑（）：实现业务规则和业务逻辑。 工作流（）：实现多用户、多环节之间的业务处理流程。 文件管理（）：管理文档，实现系统内部的文件传递。 报表打印（）：实现数据打印，实现报表的定制和输出。 门户信息发布（）：发布企业相关的信息、新闻，提供企业客户的 访问入口。 通信（）：系统内部的消息

8、、通知；系统与外部角色（比如企业客户） 之间通过不同通信媒介（电话、网站、邮件等）的互动。 特定行业领域模块（）：实现特定行业、流域相关的业务模块。以上诸方面中，除了前四项目前主要由应用服务器解决之外，其他的部分本 身都是专门的软件开发领域。框架的作用，在于确定上述每种因素的具体技术实 现，并规定它们在系统中的组织方式和协作方式，从而给出完整的企业应用解决 方案。1.2架构软件架构（）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽 象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现 阶段，这些抽象组

9、件被细化为实际的组件，比如具体某个类或者对象。在面向对 象领域中，组件之间的连接通常用接口 （计算机科学）来实现。一般而言，架构有两个要素：它是一个软件系统从整体到部分的最高层次的划分。一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作 用，则是关于这个系统本身结构的重要信息。详细地说，就是要包括架构元件（）、联结器（）、任务流（）。所谓架构元 件，也就是组成系统的核心砖瓦，而联结器则描述这些元件之间通讯的路径、 通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完 成某一项需求。下图就是一个软件系统的逻辑架构图：:HTML服务名泉虱名晒踽jXWEB Serv

10、er ApplicationServer堂主因 定肘服务系既陛理-旺颂卯篮t服务1L (EnftiL HTP5流查理）.1冬国通言宜持 系统跆砌 j任务管理*缓冲服务一 1 1表那服券交场服务L女件号入嗣务竺成口at? Acce&s1JUser Pr&ferianee湖如冬 t- u1表象层商业层数据持以晨）X- - X -建造一个系统所做出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要事先做出，而一旦系统开始进 行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必 定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。1

11、.3区别与联系首先，软件的架构是高层次的全局理念，而框架是逐步加强固化和粘滞的（不 可否认，它们也可能有灵活性的），使用固化和粘滞的物件来实现相对灵活的设 计是不恰当的做法。而通常，架构所包含的根据实际情况所作的取舍选择，有业 务架构的倾向，这个倾向包含了系统解耦合的力度和关键实现的技术选择，这个 超出了框架的适用范畴。也存在试图包罗万象的框架，但通常这不是好的选择， 如果考虑到系统复杂程度所带来的损害更加如此。但框架可以组合成为软件架 构，但最好要在强大、灵活和简单之间做出平衡，而这个平衡绝对是重要的。单 纯的组合若干优秀的框架或者基础件类而不考虑适度的取舍变化的架构设计，通 常只能够算是技

12、术的“表演”，这是不恰当的。2、软件重用及组件技术尽管当前社会的信息化过程对软件需求的增长非常迅速，但目前软件的开发 与生产能力却相对不足，这不仅造成许多急需的软件迟迟不能被开发出来，而且 形成了软件脱节现象。自世纪年代人们认识到软件危机，并提出软件工程以来， 已经对软件开发问题进行了不懈地研究。近年来人们认识到，要提高软件开发效 率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。这包 括技术和管理两方面的问题：在技术上，应该采用基于重用的软件生产技术；在 管理上，应该采用多维的工程管理模式。随着软件技术的发展，软件重用已经从模块、对象的重用发展到了基于组件 的重用和基于框架的

13、重用，这也是当前最主要的两种软件重用的方式。2.1基于组件技术的软件重用近年来人们认识到，要真正解决软件危机，实现软件的工业化生产是唯一可 行的途径。分析传统工业及计算机硬件产业成功的模式可以发现，这些工业的发 展模式均是符合标准的零部件组件生产以及基于标准组件的产品生产，其中，组 件是核心和基础。一般认为，组件是指语义完整、语法正确和有可重用价值的单位软件，是软 件重用过程中可以明确辨识的系统；结构上，它是语义描述、通信接口和实现代 码的复合体。简单地说，组件是具有一定的功能，能够独立工作或能同其他组件 装配起来协调工作的程序体，组件的使用同它的开发、生产无关。从抽象程度来 看，面向对象技术

14、以达到类级重用（代码重用），它以类为封装的单位。这样的 重用粒度还太小，不足以解决异构互操作和效率更高地重用。组件将抽象的程度 提高一个更高的层次，它是对一组类的组合进行封装，并代表完成一个或多个功 能的特定服务，也为用户提供了多个接口。整个组件隐藏了具体的实现，只用接 口对外提供服务。组件模型是对组件本质特征的抽象描述。目前，国际上已经形成了许多组件 模型，这些模型的目标和作用各不相同，其中部分模型属于参考模型（例如模型）， 部分模型属于描述模型（例如模型和模型）。还有一部分模型属于实现模型。近 年来，已形成三个主要流派，分别是（，对象管理集团）的（，通用对象 请求代理结构）、的（）和的（，

15、分布式组件对象模型），这些实现模型将 组建的接口和实现进行了有效的分离，提供了组件交互能力，从而增加了重用的 机会，并适应了目前网络环境下大型软件系统的要求。在组件库管理系统方面。美国军方与政府资助的项目监理了组件库系统 如、等。基于开放体系结构，项目就组件库之间共享资源和无缝互操作问题， 提交了 （，开放体系结构的组件库框架）版本。该框架体系给出了一个组件库架构的参考模型，实现了 规约作为该模型的实例，证明了以公共元素为基 础，在组件库之间交换信息和创建易于移植的复用工具是可行的和必要的。可复 用库互操作组织（）提出了解决组件互操作方案 和，其中 是 的子集， 定义了实现互操作、复用库间交换

16、软件组件所需的信息的最小集合。组件软件设计的一些主要技术如下：组件标准接口技术组件之间如何实现通讯是组件软件理论的重要的技术之一，这需要定义一套 标准接口，组件间的互操作性要求接口统一；从软件复用的角度来讲，为了保证 组件能够被其他应用系统重复利用，也需要实行统一的标准接口。因此接口技术 特征就代表了不同的组件模型标准。接口技术包括了接口的定义和唯一标识、接 口函数的调用、接口与对象的关系以及接口所具有的特性等。这些都是每种接口 规范必不可少的，组件的良好构造、相互间的集成都需要对接口进行严格地规范 定义。组件库管理技术组件软件技术的框架就是对现成的合适组件进行应用集成，随着组件的不断 增加，

17、为了便于对组件进行区分和识别，需要建立组件库加以管理。组件库中可 以包括购买的第三方开发的商业组件、完全自主开发的组件、或者经改造后的第 三方开发的组件。在软件工厂里，组件库的管理应该由高级人员来负责，如系统 分析人员，因为在应用系统的设计中，系统分析员不仅需要对需求有清楚的了解， 还需要多已有得各种组件功能了如指掌，这样有利于快速设计性能优良的软件框 架。组件库管理技术涉及到组件各种特性的标识、分类技术、登记办法、检索机 制及其它相关处理等等。组件库的管理对模块化的软件开发具有非常重要的意义，一个良好的组件库 无疑会提高软件设计速度、增加软件应用系统的性能。组件的组装集成技术组装技术也是一个

18、相当重要的技术难题之一，尤其是软件组件的组装比生产 车间里机械零部件的组装存在更多的兼容性、组建功能上的不完全匹配、运行在 网络环境的各种组件状态、系统的稳定性分析、处于磨合期发生的症状等，这些 都是组件软件系统集成中要解决的。2.2基于框架技术的软件重用从重用粒度上看，框架要比组件大。框架重用是一种面向领域的软件重用方 式。框架一般建立在同一个或相似领域中，即所要开发的软件系统要具有较强的 相似性，通过框架把领域中不变或易变的部分在一定时间间隔内固定下来，把易 变的部分以用户接口的形式保留下来，从而达到设计和代码的重用。框架技术与 组件技术的结合产生了基于组件的应用框架技术，这是框架技术的一

19、个发展趋 势。框架的定义和描述最早的对框架描述由在年给出：“多个抽象类和它们相关算法的集合可组成 一个框架，该框架在特定应用中可以通过专用代码的添加将具体子类组织在一起 运作。框架由抽象类及其实现的操作和对具体子类的期望组成。”其他对框架有以下比较重要的定义和描述。和在年给出的定义：框架是封装了特定应用族抽象设计的抽象类的几何，框 架又是一个模板，关键的方法和其他细节在框架实例中实现。:框架是一个可实例化的、部分完成的软件系统或子系统，定义了一组系统 或子系统的体系结构并提供了构造系统的基本构造模块，还定义了对特殊功能实 现所需要的调整方式。在一个面向对象的环境中，框架由抽象类和具体类组成；

20、框架的实例化包括现有类的实例化和衍生。:框架 模式 组件。框架式开发人员定制的应用系统的骨架，使整个系统 或子系统的可重用设计，由一组抽象组件和组件实例间的交互方式组成。以上是对一般框架概念的描述，对应用框架的描述和定义主要有：:应用框架又称为通用应用，是为一个特定应用领域的软件系统提供可重用 结构的一组相互协作的类的集合。:特定领域应用的框架成为应用框架。:应用框架就是某个领域公共问题的骨架式解决方案。框架为该领域所有应 用提供公共的体系结构和功能基础。:应用框架技术适用于应用产品线的、通用的、面向对象的代码结构化技术。 一个框架就是表达抽象设计的抽象类的集合；框架实例就是为可执行子系统提供

21、 的抽象类的子集的具体类的集合。框架是为了重用而设计的：抽象类封装了公共 代码，具体类封装特定实例的代码。经过分析，可以得出以上众多对应用框架的描述的共同点是：应用框架解决的是一个领域或产品族的问题，规定了问题应该如何分解。包含了应用或子系统的设计，由一个相互协作的类或组件集合组成。可以通过继承或类的组合来创建应用。框架技术的基本特征总结如下：反向控制：类库是客户代码调用库中已存在类的方法，框架内嵌了控制 流，框架调用客户代码一一加入框架的新组件和抽象类的方法实例。可重用性：框架提供了设计和代码的重用能力。扩展性：为规划的变化提供了热点（）或钩子（）等显式说明方式。模块化或组件化：框架由固定的

22、、稳定的接口和封装的热点。框架的实现技术一般框架有三种建立方式：自顶向下、自底向上和混合方式。前两种框架建 立方式与建立全新的软件产品线时的演化方式十分类似，也具有相同的过程和优 缺点。混合方式指在大型应用框架的建立过程中，先将应用领域划分为不同的子 区域，再分别解决，最终集成为一个完整框架的做法。根据框架的使用和扩展方式，可以将框架分为两大类：黑盒框架和白盒框架。黑盒框架通过组件类的组合来支持重用和扩展。应用中的类由框架的不同组 件组合而成。在框架所在领域中，每个组件都有一个预定义的标准接口，一组共 享相同接口但能满足不同应用需求的组件组成一个“插接兼容”的组件集合。白盒框架一般使用类的集成

23、机制实现，由未完成的类（抽象类）组成，类有 一个或多个抽象接口或虚方法。应用需要在抽象类的继承子类中提供特定意义的 方法实例来重用框架。开发者通过虚方法的实例化将特定应用的代码嵌入框架来 生成应用，所以虚方法又成为“钩子”或“热点”。白盒重用需要对框架有很好的理解，生成紧耦合系统。黑盒重用不需要对框 架的内部结构有太多的了解，产生松耦合系统。具体的框架实际上都是“灰色” 的，是可继承和可组合方式的结合。灰色框架可以分成三部分：固定的、可选择的和开放的。框架的固定部分包 含了该领域最基本的功能，内建了应用的控制流，有框架主干实现，对应着领域 共用部分。框架的可选择部分为该领域中相对固定的、应用特

24、定的功能特征即领 域个性部分，用可组合的类或组件实现，在应用构造时在这些组件或类中进行选 择、组合。对一些无法准确估计和预测的功能特征即框架的开放部分，只能为其 规定统一的接口和与框架的挂接点，用可继承的抽象类的方法来实现，这些部分 可以根据应用的具体需求变化进行单独的调整。与体系结构的层次类似，框架也可设计为层次结构，可称之为层次框架。例 如把一个完整的框架划分为：应用框架、领域框架、支撑框架多个层次，框架层 次间是标准的或统一的接口。层次框架与层次体系结构具有相同的优点。框架其实就是一组组件，供你选用完成你自己的系统。简单说就是使用别人 搭好的舞台，你来做表演。而且，框架一般是成熟的，不断

25、升级的软件。可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐 明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽 象类以及其实例之间协作的方法，它为构件复用提供了上下文（）关系。因此构件 库的大规模重用也需要框架。构件领域框架方法在很大程度上借鉴了硬件技术发展的成就，它是构件技 术、软件体系结构研究和应用软件开发三者发展结合的产物。在很多情况下，框 架通常以构件库的形式出现，但构件库只是框架的一个重要部分。框架的关键还 在于框架内对象间的交互模式和控制流模式。框架比构件可定制性强。在某种程度上，将构件和框架看成两个不同但彼此 协作的技术或许更好。框架为构件

26、提供重用的环境，为构件处理错误、交换数据 及激活操作提供了标准的方法。应用框架的概念也很简单。它并不是包含构件应用程序的小片程序，而是实 现了某应用领域通用完备功能（除去特殊应用的部分）的底层服务。使用这种框 架的编程人员可以在一个通用功能已经实现的基础上开始具体的系统开发。框架 提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类（该子类属 于框架的默认行为）或组装对象来支持应用专用的行为。应用框架强调的是软件的设计重用性和系统的可扩充性，以缩短大型应用软 件系统的开发周期，提高开发质量。与传统的基于类库的面向对象重用技术比较， 应用框架更注重于面向专业领域的软件重用。应用框架具有领

27、域相关性，构件根 据框架进行复合而生成可运行的系统。框架的力度越大，其中包含的领域知识就更加完整。3、开发框架的意义和选取原则3.1开发框架的意义企业应用框架是菜场里的半成品。当我们面对要么自己下厨、要么去饭馆吃 饭的选择时，我们往往会采取这种省时省力的折衷方案。但是选择之所以为选择， 就因为其中肯定包含对收益和代价的权衡，都隐含着复杂的利弊关系（优点和缺 点）。下面我们也来讨论一下企业应用框架的情况：优点：*缩短开发周期毫无疑问，采用框架的开发，要比一切从头做起快速、高效得多。通过一般 化（）和重用（）机制，框架能最大限度地加快一个特定应用系统的实现。*客户化如上所述，基于框架的系统有很多功

28、能通过配置而不是编程实现，这样也给 用户带来了一定便利。比如，企业内部的人员经过一定培训，就能够自己完成一 种新的工作流程的设置。这对于不断变化的业务需求是一个很理想的解决方案。*不重新发明轮子框架对于大量典型场景给出了最优的实践。在具体开发时，与其无视前人的 成果，重新构思答案，不如套用这些成熟、稳定的做法。这不仅能加快开发进度， 更能够提升系统的质量和健壮性。*可维护性知识共享完全通过委托开发完成的系统很难由其他厂商维护。框架往往是多个企业、 大量开发者实践的成果，因此能在一定程度上打破上述壁垒，增进系统的可维护 性。当框架使用者形成社区之后，还能实现更高层次上的知识共享。缺点：* “太多

29、”半成品总有其代价。超市配好的一包菜里，老是有我们用不到的调料一一但 是我们却不得不为之付费。同样，为了达到一般性和普适性，框架总比紧凑、贴 切的特定应用多出不少内容。二次开发完成后，企业获得的只是一种特定的实现， 却要为所有的客户化可能性付费，为所有用不上的功能付费。这是一个相当让人 尴尬的事实。* “太少”框架总是一种限制。就像半成品菜限制了我们的烹调方法，框架也限制了我 们实际应用的可能性。当框架本身设计的足够普适时，我们不太会感到类似的限 制。但是，情况往往正好相反一一面对一个足够特殊的需求，二次开发者总有一 种冲破框架的渴望。最后的解决办法，往往是狡计、妥协和框架补丁的结合体。*效率

30、上面说过，基于框架的系统中，具体功能经常是通过配置实现的。与硬编码 （）的方式相比较，这虽然能提供很大的灵活性，但也往往牺牲了运行时的效率。*锁定一个采用特定框架的系统几乎肯定被锁定在这个厂商的产品上。换言之，框 架意味着 式的态度，很难调和两种不同的框架，各取所长，更难把应用系统从 一个框架迁移到另一个一一这往往要求系统的全部改写。*学习曲线一种框架也就是一种方言。要精通特定框架的开发，你要熟悉其中的所有的 用法、思路和弱点。对于开发者，这也意味着比较陡峭的学习曲线。3.2设计的原则和评判标准对于如何判断一个软件的系统框架的优劣，笔者认为，可以从以下几个方面 来评判：系统的内聚和耦合度。这是

31、保证一个系统的架构是否符合软件工程原则 的首要标准。层次的清晰和简洁性。系统每个部分完成功能和目标必须是明确的，同 样的功能，应该只在一个地方实现。如果某个功能可以在系统不同的地 方实现，那么，将会给后来的开发和维护带来问题。系统应该简单明了， 过于复杂的系统架构，会带来不必要的成本和维护难度。在尽可能的情 况下，一个部分应该完成一个单独并且完整的功能。易于实现性。如果系统架构的实现非常困难，甚至超出团队现有的技术 能力，那么，团队不得不花很多的精力用于架构的开发，这对于整个项 目来说，可能会得不偿失。可升级和可扩充性。一个系统框架，受设计时技术条件的限制，或者设 计者本人对系统认识的局限，可

32、能不会考虑到今后所有的变化。但是， 系统必须为将来可能的变化做好准备，能够在今后，在目前已有的基础 上进行演进，但不会影响原有的应用。接口技术，是在这个方面普遍应 用的技巧。是否有利于团队合作开发。一个好的系统架构，不仅仅只是从技术的角 度来看，而且，它还应该适用于团队开发模型，可以方便一个开发团队 中各个不同角色的互相协作。例如，将页面和业务逻辑组件分开，可是 使页面设计人员和程序员的工作分开来同步进行而不会互相影响。性能。性能对于软件系统来说是很重要的，但是，有的时候，为了能让 系统得到更大的灵活性，可能不得不在性能和其他方面取得平衡。另外 一个方面，由于硬件技术的飞速发展和价格的下降，性

33、能的问题往往可 以通过使用更好的硬件来获得提升。4、理想的框架4.1基于的系统开发框架基于的企业级应用体系结构是拓展了当前的分布式应用程序体系结构的思 想。它引入了组件技术、服务技术和通信技术，依靠通信、服务技术的支持，系 统通过访问服务器端组件来完成系统的业务处理功能。由服务器端组件来完成系 统的业务处理功能。随着软件工程技术的发展，特别是面向对象技术的出现和应 用，基于数据和行为封装的对象技术使基于组件技术的企业级应用体系结构实现 成为可能。通过开发和扩展系统的中间件，将不同的应用功能组件化使多个应用 程序使用一组共同的组件，简化系统结构，实现软件的复用。（）企业体系结构是公司为了增强在系

34、统服务器端的应用而推出的一个 完整的基于应用系统的开发规范，是基于应用语言开发服务器端组件规范而开发 出的能提供平台无关、可移植、多用户、安全和标准的企业级服务器端部署平台。 是通过一个基于组件的应用程序模型为分布式应用程序提供一个统一的开发规 范和标准，通过指定应用程序的功能和接口，以及部署应用程序的运行环境，提 供了应用程序与运行基础结构的明确分界线，使应用程序开发人员可以集中考虑 应用程序逻辑和相关服务。基于开发规范构造基于的软件应用系统主要有以下优势：独立于系统平台：应用软件拥有的跨平台特性，增强了软件的适应性；集成企业信息资产：系统可以在企业已有的信息系统的基础上开发，并 可以使用其

35、信息资源；系统开发效率高：可以使开发人员使用中间件供应商提供的中间件来负 责通用的、复杂和繁琐的服务器端任务，而主要开发业务处理组件，提 高了开发速度，适应不同企业软硬件环境；实现了软件复用：根据系统的要求，开发人员可以集成不同的已有组件 完成整个应用系统的开发；可扩展性高：基于开发的应用程序可以部署到各种操作系统中；系统稳定性、持续性和安全性高：为应用系统提供了良好的安全和运 行模型，系统可以稳定高效地运行。从本质上来讲，是一大堆标准化的企业机服务一一例如命名和目录服务()、 为异构的事物性资源提供了标准事物管理接口 (和)、连接遗留系统的标准机制()、 资源池、线程管理等一一的集合体。()

36、是经典的中的重要组成部分，它定义了编写服务器端组件的规范，并 提供了服务器端组件和管理这些组件的应用服务器之间的协议。然而，企业实际应用证明，对于所有基于构架建立的应用系统，都存在以下 问题：需要容器。这意味着系统需要高端的应用服务器支撑，而且比引擎管理 起来复杂得多； 在客户端层需要服务定位器或业务代理，调用复杂； 需要一些细粒度对象运行在会话门面之后、容器之中，管理这些对象会 产生一些问题。即便是本地，最好也应该定义为相对粗粒度的对象，所以，为了管理后面的细粒度对象，我们需要一个额外的基础框架，虽然 部署描述符提供了一种专门的机制，可以在中声明“环境变量”，但是 要想达到非常细粒度的配置，

37、这种做法还是太繁琐，没有为助手类提供 生命周期支持；一旦开始把业务逻辑放在容器中，代码中加入很多容器接口实现，我们就很难替换它。如果有几个业务对象需要完成的任务是编程模型禁止的，如创建线程、开启网络连接、读取文件、调用第三方、或者是调用 本地代码等，那就会出现问题；技术复杂，开发成本高。针对构架的如上缺点，目前比较流行的一个解决方案是采用“轻量级容器” 构架构建系统。下面是基于“轻量级容器的”系统一一框架结构图。Http ： 4 BrowerHttp表示层 业务层 持久层ResPC3Struts-config.xmlDatabaseActionFormAction图的三层体系结构4.2基于框架

38、技术的实现框架是指一个特定领域中的一组相互协作的类，它是特定领域软件系统可以 复用的设计和部分实现。该特定领域软件的开发人员能够运用继承、合成等方法 定制和复用框架，开发特定的软件系统。可以说框架的复用是软件生产中最有效 的复用方式之一，能尽可能地复用已有的比较成熟的应用框架也是最经济的开发 模式。应用框架是一种面向应用领域的框架。当前在开放源代码运动的推动下， 基于体系的应用领域应用框架层出不穷，其中不乏优秀的设计，如基于 模式 的、处理持久层的以及服务于所有层面的等等。由于各种应用框架数目繁多， 且没有公认的最好框架，因此如何更好地复用它们就成为我们面临的问题。大部分应用在职责上一般分为三

39、层：表示层，处理用户请求，数据信息格式 化。它通常由容器运行，包括、等组件；业务层，处理与领域相关的具体业务逻 辑，事物管理等；持久层，处理业务对象的持久化问题，通常与数据库相关。下 图是我们设计的基于三层分类的应用框架整合模型图。图应用框架整合模型图上图中的模型基本思想是基于应用分层框架模式的，用户可以根据实际应用 需求，选择相应层次（如表示层、业务层、持久层）的最适合框架，将它们整合， 形成一个更高层次的框架。特别地，我们在传统的三层构架模式基础上，增加了 两个中间层，即服务定位层和数据接口层，这样做的好处是可以进一步降低层次 间的耦合度。下面我们具体分析应用框架整合模型图的特点：（）采用

40、设计模式，有效地对层关系进行解耦所谓解耦就是降低耦合度。我们希望对框架进行整合后能得到一个具有好的 开放性和灵活性的框架模型，这就要求所得到的框架模型的各个层面的子框架间 能做到松散耦合，这样在实际应用中，可以根据需要很容易地替换掉某个层面的 子框架而不影响其它层面。这一目标的实现关键就是子框架间的解耦问题，设计 模式提供了一个好的解决方法。设计模式是针对反复出现的设计问题给出的、经 过实践检验的、可复用的解决方案。通常，设计模式与领域无关，可用于不同的 应用系统和不同的领域，它记录了现有的、专家的设计知识，可以用来为具体的 设计问题提供适当的解决办法；而框架是一种可复用的、可适配的软件，它要

41、有 灵活的结构以易于扩展。框架中通常可能包含若干个设计模式，而设计模式比框 架具有更高的抽象性和更好的通用性。可见，设计模式和框架二者既有联系又有 区别，正因如此，在我们的模型中，可以将设计模式方法深化到框架整合中，从 而有效地对持久层子框架和业务层子框架、表示层子框架和业务层子框架解耦， 使得各个层面间子框架之间松散耦合。持久层子框架和业务层子框架解耦为了对持久层子框架和业务层子框架解耦，整合模型中采用了设计模式中 的数据访问对象模式（），在持久层子框架和业务层子框架间增加了数据接口层。 模式通过接口和实现分离的方式，完全向上层隐藏了数据源实现细节。当低层数 据源实现变化时，向客户端提供的接

42、口不会变化，所以该模式允许调整到不同 的存储模式，而不会影响其上层。重要的是，充当了业务层和数据源之间的适 配器，将低级别的数据访问逻辑与高级别的业务逻辑分离。因此通过在业务层子 框架和持久层子框架间增加了数据接口层，能有效地降低两者的耦合度。 表示层子框架和业务层子框架解耦为了降低表示层子框架和业务层子框架间的耦合度，整合模型采用 另一个 常用模式一一模式，提供了一个通用的服务定位层。服务定位器模式中有一个对 象（即服务定位器）知道如何获得一个应用程序所需的所有服务。整合模型中表 示层子框架需要请求业务层子框架服务时，将向服务定位器层发出请求，间接获 取相应的业务服务对象接口，而不是直接向业

43、务层请求。整合模型提供的这个服 务定位层是与特定框架无关的，它根据配置文件里定义的服务映射关系来寻找 表示层所需的业务服务对象，从而降低了业务层子框架和持久层子框架间的耦合 度。（）引入一组编程约束，解决功能冗余问题应用框架有的是针对多层次的，甚至是所有层次的，如框架。但是仅仅选 用其特定层面的功能，这时功能冗余问题就出现了。我们的整合模型针对应用于 各个层次的子框架，提出了一组约束，将某个特定的框架功能限定于特定的层次， 这样可以有效解决功能冗余问题。我们提出的约束如下：针对表示层子框架的约束一个典型的应用的末端应该是表示层。我们规定表示层子框架的主要功能 有：管理用户的请求，作出相应的响应

44、；为显示提供一个模型。而不该在表示层 子框架实例化编码中出现的，与表示层无关的部分，作出不可以出现的约束。不 可以出现在表示层子框架中的有：直接地与数据库通信，例如 调用；与应用程 序相关联的业务逻辑以及校验；事务管理。如果不作出这些约束规定，在表示层 框架编码中引入这些代码，则会带来高耦合和麻烦的维护。针对业务层子框架的约束我们规定可以在业务层子框架中出现的主要功能有：处理应用程序的业务逻 辑和业务校验；管理事务；允许与其它层相互作用的接口；管理业务层级别的对 象依赖；管理程序的执行（从业务层到持久层）。针对持久层子框架的约束可以在持久层子框架中出现的主要功能有：查询对象的相关信息语句；如何

45、 存储、更新、删除数据库记录；支持大部分主流数据库，并且支持关系，事务 处理，继承和多态。（）引入域对象层，能有效地解决框架通信问题在框架整合过程中，层间框架通信问题也是一个难以解决的常见问题。为了 有效解决框架通信问题，我们的模型引入了域模块层，域模块层由实际需求中的 业务对象组成，它为联系各个层面提供了一个纽带，有了域模块层，业务领域对 象信息就能够在层间进行传递，我们仅需关注域对象即可。根据以上的应用框架整合模型图结构及其特点分析，我们研究了目前比较优 秀的开源框架项目，并整合了优秀的框架，作为飞机制造质量管理系统的开发平 台。业务服务对免接口_LL. JJ服务八象、接 1事物管理业务服

46、务对象1Spring框架AOPCore会话管理持久层服务定位器层服务定位器数据接口层客户端浏览器询据二数据接口对象数据接口对象A/ 业务层 atp框架XML映射Hibernate数据库J/L4 /-F配置文件图基于开源框架集成的信息管理系统软件平台下面我们具体描述该平台的实现技术及集成技术：（）域对象层域对象层是连接各层的纽带，首先要创建域对象（即域对象层中的对象）并且 确认域对象中哪些是需要持久化的，哪些是提供给业务层的，哪些是显示接口设 计的。这层是编码的开始，也就是包中的模型文件。域对象是由简单对象（）编 写的，因此具有良好的重用性和可扩展性。（）业务层业务层处于整个应用的中心，负责业务

47、对象的管理和维护。传统的应用中， 业务层对象的管理容器一般是容器，容器提供了一个定义良好的服务层，然而却 是一个重量级的框架：访问组件相当困难，且需要它本身的基础设施，这都让客 户端变得复杂;无法轻松的在容器外对进行配置;无法管理细粒度对象（如组件）， 因此，我们需要一个轻量级的业务组件管理容器替代它。业务框架选择的一个重要原则是要避免业务应用代码对容器的依赖，这种功 能就是所谓的控制反转（，）。的实现有两种方式，依赖查找（）和依赖注入（）。容器采用的就是前者实现方 法，容器提供回调接口和上下文环境给组件，组件自己使用容器提供的查找资源 和协作对象，容器给用户提供的是一种入侵式的管理，因此造成以上所说的不足。 依赖注入是让容器去全权负责依赖查找，受管对象只需要暴露的方法或者带参数 的构造子，使容器可以在初始化时组装对象的依赖关系。这种控制反转的方式使 得依赖的查找定位操作与应用代码完全无关，不依赖容器的，不需要特殊的接口 这也就是轻量级容器与重量级容器的主要区别。框架是轻量级容器的一个优秀代表，具有很强大的管理能力，因此，我们采 用作为业务层的框架，用一个业务服务对象接收一个数据接口层的数据访问接口 对象，用它