开发框架的选择

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

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

3、业界，“平台 platform 、“框架 framework、 “构架architecture等等就是这种人见人爱的概念。几乎每个厂商都愿意请 来其中的一位、 甚至多位为自己推销。 久而久之，这些说法似乎适用于各个领域、 各个层面：所有的软件系统都是“平台 ，所有的开发者都在沉迷于独有的“框 架。原本有确切意义的“好词 ，经过这一番争夺和滥用，也只能衰减为所谓的“buzzwords，供市场营销人士们玩味了。理解企业应用框架 选择自kxiangli 的 Blog1.1 框架软件业圣经?设计模式?对框架有如下定义： “ A framework is a set of cooperati ng cl

4、asses that make up a reusable desig n for a specific class of softw一 个框架，就是一组相互协作的类； 对于特定的一类软件， 框架构成了一种可重用 的设计。这个定义虽然主要着眼于面向对象的软件开发， 但已经根本上给出了 这个词的核心含义： 框架是软件系统的设计、 开发过程中的一个概念， 它强调对 已完成的设计、 代码的重复使用， 并且，一个框架主要适用于实现某一特定类型 的软件系统。为了更好地说明框架是什么，也许还应该看看框架不是什么。 框架不是现成可用的应用系统。它仍是一个半成品，等待后来者做“二 次开发，实现为具体的应用系统

5、。 框架不是“平台。后者的概念更加浮泛和模糊人们说的一个平台， 可以是一种操作系统，一种应用效劳器，一种数据库软件，一种通信中 间件等等，因此“平台几乎成了所有系统软件的统称。在平台的大家 族中，框架的概念可能与近来人们常说的“应用平台最为接近，但平 台主要指提供特定效劳的系统软件， 而框架那么更侧重于设计、 开发过程， 或者可以说，框架通过调用平台提供的效劳而起作用。框架不是工具包toolkit: /类库library/API。目前流行的很多框架 中，就包括了大量的类库和 API，但是调用API并不就是在使用框架开 发。仅仅使用 API 时，开发者完成系统的主体局部，并不时地调用类库 实现特

6、定任务。 而框架构成了通用的、 具有一般性的系统主体局部， “二 次开发者只是像做填空题一样，根据具体业务，完成特定应用系统中 与众不同特殊的局部。框架不是构架architecture 0构架确定了系统整体结构、层次划分、不 同局部之间的协作等设计考虑。 框架比构架更具体， 更偏重于技术实现。 确定框架后，构架也随之确定，而对于同一种构架比方 web 开发中的 MVC ,可以通过多种框架比方Apache Struts或WebWork实现。理 解企业应用框架 选择自 kxiangli 的 Blog 如何最大程度地萃取不同企业应用系统的共性， 重复使用已经完成的设计和 代码，对企业应用系统中典型场

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

8、l：在大量并发访问时，保持系统可用。监控system moritorirg/maragemer： 监控系统运行状况，设置系统参数。日志loggirg：记录系统运行情况和异常，记录特定用户操作。应用集成 即plicatior irtegratior：与其他系统、应用程序集成。 认证/权限/组织角色管理autherticatior/authorizatior：管理系统用 户、组织职权结构，限制特定用户对特定功能、特定数据的访问。 业务模型domair model:管理系统中业务对象的属性、字段。 业务逻辑busiress logic/rulesJ:实现业务规那么和业务逻辑。工作流 work flo

9、w ：实现多用户、多环节之间的业务处理流程。文件管理file maragemer：管理文档，实现系统内部的文件传递。 报表/打印reportirg/prirtirg：实现数据打印，实现报表的定制和 输出。门户/信息发布portal solutior：发布企业相关的信息、新闻，提供 企业客户的访问入口。通信commuricatior/messagirg：系统内部的消息、通知；系统与外部角色比方企业客户之间通过不同通信媒介、网站、邮件等的互动。特定行业/领域模块 busiress modules:实现特定行业、流域相关的业务模块以上诸方面中， 除了前四工程前主要由应用效劳器解决之外， 其他的局部本

10、 身都是专门的软件开发领域。 框架的作用， 在于确定上述每种因素的具体技术实 现，并规定它们在系统中的组织方式和协作方式， 从而给出完整的企业应用解决1.2 架构软件架构software architecture是一系列相关的抽象模式，用于指导大型 软件系统各个方面的设计。 软件架构是一个系统的草图。 软件架构描述的对象是 直接构成系统的抽象组件。 各个组件之间的连接那么明确和相对细致地描述组件之 间的通讯。 在实现阶段， 这些抽象组件被细化为实际的组件， 比方具体某个类或 者对象。在面向对象领域中，组件之间的连接通常用接口电脑科学 来实现。一般而言，架构有两个要素：它是一个软件系统从整体到局

11、部的最高层次的划分。一个系统通常是由元件组成的， 而这些元件如何形成、 相互之间如何发生作 用，那么是关于这个系统本身结构的重要信息。详细地说，就是要包括架构元件Architecture Component、联结器 Connecto、任务流Task-flow。所谓架构元件，也就是组成系统的核心"砖 瓦"，而联结器那么描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果， 任务流那么描述系统如何使用这些元件和联结器完成某一项需求。列图就是一个软件系统的逻辑架构图：图1建造一个系统所做出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要

12、事先做出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。 显然，这样的决定必 定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。1.3区别与联系首先，软件的架构是高层次的全局理念，而框架是逐步加强固化和粘滞的不 可否认，它们也可能有灵活性的，使用固化和粘滞的物件来实现相对灵活的设 计是不恰当的做法。而通常，架构所包含的根据实际情况所作的取舍选择， 有业 务架构的倾向，这个倾向包含了系统解耦合的力度和关键实现的技术选择，这个超出了框架的适用范畴。也存在试图包罗万象的框架，但通常这不是好的选择， 如果考虑到系统复杂程度所带来的损害更加如此。但框架可以组合成为软件

13、架 构，但最好要在强大、灵活和简单之间做出平衡，而这个平衡绝对是重要的。单 纯的组合假设干优秀的框架或者根底件 / 类而不考虑适度的取舍变化的架构设 计，通常只能够算是技术的“表演 ，这是不恰当的。2、软件重用及组件技术尽管当前社会的信息化过程对软件需求的增长非常迅速， 但目前软件的开发 与生产能力却相对缺乏， 这不仅造成许多急需的软件迟迟不能被开发出来， 而且 形成了软件脱节现象。 自20世纪 60年代人们认识到软件危机， 并提出软件工程 以来，已经对软件开发问题进行了不懈地研究。 近年来人们认识到， 要提高软件 开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。 这包

14、括技术和管理两方面的问题： 在技术上，应该采用基于重用的软件生产技术； 在管理上，应该采用多维的工程管理模式。随着软件技术的开展， 软件重用已经从模块、 对象的重用开展到了基于组件 的重用和基于框架的重用，这也是当前最主要的两种软件重用的方式。2.1 基于组件技术的软件重用近年来人们认识到， 要真正解决软件危机， 实现软件的工业化生产是唯一可 行的途径。 分析传统工业及电脑硬件产业成功的模式可以发现， 这些工业的开展 模式均是符合标准的零部件 /组件生产以及基于标准组件的产品生产，其中，组 件是核心和根底。一般认为， 组件是指语义完整、 语法正确和有可重用价值的单位软件， 是软 件重用过程中可

15、以明确辨识的系统； 结构上， 它是语义描述、 通信接口和实现代 码的复合体。 简单地说，组件是具有一定的功能， 能够独立工作或能同其他组件 装配起来协调工作的程序体， 组件的使用同它的开发、 生产无关。 从抽象程度来 看，面向对象技术以到达类级重用代码重用 ，它以类为封装的单位。这样的 重用粒度还太小， 缺乏以解决异构互操作和效率更高地重用。 组件将抽象的程度 提高一个更高的层次， 它是对一组类的组合进行封装， 并代表完成一个或多个功 能的特定效劳， 也为用户提供了多个接口。 整个组件隐藏了具体的实现， 只用接 口对外提供效劳。组件模型是对组件本质特征的抽象描述。 目前，国际上已经形成了许多组

16、件 模型，这些模型的目标和作用各不相同，其中局部模型属于参考模型例如 3C 模型，局部模型属于描述模型例如 RESOLVE 模型和 REBOOT 模型。还有 一局部模型属于实现模型。 近年来， 已形成三个主要流派， 分别是 OMGObject Management Group 对象管理集团的 CORBACommon Object Request Broker Architecture，通用对象请求代理结构、Sun 的 EJB Enterprise Java Bean和 Microsoft 的 DCOMDistributed Component Object Model,分布式组件对象模型， 这

17、些实现模型将组建的接口和实现进行了有效的别离， 提供了组件交互能力， 从 而增加了重用的时机，并适应了目前网络环境下大型软件系统的要求。在组件库管理系统方面。美国军方与政府资助的工程监理了组件库系统如CARDS、ASSET、DSRS等。基于开放体系结构，STARS工程就组件库之间共 享资源和无缝互操作问题，提交了 ALOAF Asset Library Open Architecture Framework，开放体系结构的组件库框架1.2版本。该框架体系给出了一个组 件库架构的参考模型，实现了 ALOAF 规约作为该模型的实例，证明了以公共 元素为根底，在组件库之间交换信息和创立易于移植的复用

18、工具是可行的和必要 的。可复用库互操作组织Reuse Library In teroperability Group提出了解决组件 互操作方案 BIDM 和 UDM ，其中 BIDM 是 UDM 的子集，定义了实现互操 作、复用库间交换软件组件所需的信息的最小集合。组件软件设计的一些主要技术如下：组件标准接口技术 组件之间如何实现通讯是组件软件理论的重要的技术之一， 这需要定义一套 标准接口， 组件间的互操作性要求接口统一； 从软件复用的角度来讲， 为了保证 组件能够被其他应用系统重复利用， 也需要实行统一的标准接口。 因此接口技术 特征就代表了不同的组件模型标准。 接口技术包括了接口的定义和

19、唯一标识、 接 口函数的调用、 接口与对象的关系以及接口所具有的特性等。 这些都是每种接口 标准必不可少的， 组件的良好构造、 相互间的集成都需要对接口进行严格地标准 定义。组件库管理技术组件软件技术的框架就是对现成的适宜组件进行应用集成， 随着组件的不断 增加，为了便于对组件进行区分和识别， 需要建立组件库加以管理。 组件库中可 以包括购置的第三方开发的商业组件、 完全自主开发的组件、 或者经改造后的第 三方开发的组件。 在软件工厂里， 组件库的管理应该由高级人员来负责， 如系统 分析人员，因为在应用系统的设计中， 系统分析员不仅需要对需求有清楚的了解， 还需要多已有得各种组件功能了如指掌，

20、 这样有利于快速设计性能优良的软件框 架。组件库管理技术涉及到组件各种特性的标识、 分类技术、登记方法、 检索机 制及其它相关处理等等。组件库的管理对模块化的软件开发具有非常重要的意义， 一个良好的组件库 无疑会提高软件设计速度、增加软件应用系统的性能。组件的组装集成技术组装技术也是一个相当重要的技术难题之一， 尤其是软件组件的组装比生产 车间里机械零部件的组装存在更多的兼容性、 组建功能上的不完全匹配、 运行在 网络环境的各种组件状态、 系统的稳定性分析、 处于磨合期发生的病症等， 这些 都是组件软件系统集成中要解决的。2.2 基于框架技术的软件重用从重用粒度上看， 框架要比组件大。 框架重

21、用是一种面向领域的软件重用方 式。框架一般建立在同一个或相似领域中， 即所要开发的软件系统要具有较强的 相似性，通过框架把领域中不变或易变的局部在一定时间间隔内固定下来， 把易 变的局部以用户接口的形式保存下来， 从而到达设计和代码的重用。 框架技术与 组件技术的结合产生了基于组件的应用框架技术，这是框架技术的一个开展趋 势。2.2.1 框架的定义和描述最早的对框架描述由Deutsch在1983年给出：“多个抽象类和它们相关算法 的集合可组成一个框架， 该框架在特定应用中可以通过专用代码的添加将具体子 类组织在一起运作。框架由抽象类及其实现的操作和对具体子类的期望组成。 其他对框架有以下比拟重

22、要的定义和描述。Johnson和Foot在1988年给出的定义：框架是封装了特定应用族抽象设计 的抽象类的几何，框架又是一个模板，关键的方法和其他细节在框架实例中实现。Buschmann框架是一个可实例化的、局部完成的软件系统或子系统，定义 了一组系统或子系统的体系结构并提供了构造系统的根本构造模块， 还定义了对 特殊功能实现所需要的调整方式。 在一个面向对象的环境中， 框架由抽象类和具 体类组成；框架的实例化包括现有类的实例化和衍生。Johnson框架=模式+组件。框架式开发人员定制的应用系统的骨架， 使整个系统或子系统的可重用设计， 由一组抽象组件和组件实例间的交互方式组 成。以上是对一般

23、框架概念的描述，对应用框架的描述和定义主要有：Gamma：应用框架又称为通用应用，是为一个特定应用领域的软件系统提 供可重用结构的一组相互协作的类的集合。Buschmann特定领域应用的框架成为应用框架。Froehlich :应用框架就是某个领域公共问题的骨架式解决方案。框架为该领 域所有应用提供公共的体系结构和功能根底。Batory:应用框架技术适用于应用产品线的、通用的、面向对象的代码结构 化技术。一个框架就是表达抽象设计的抽象类的集合； 框架实例就是为可执行子 系统提供的抽象类的子集的具体类的集合。 框架是为了重用而设计的： 抽象类封 装了公共代码，具体类封装特定实例的代码。经过分析，可

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

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

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

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

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

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

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

31、能最大限度地加快一个特定应用 系统的实现。* 客户化 如上所述，基于框架的系统有很多功能通过配置而不是编程实现， 这样也给用户带来了一定便利。比方，企业内部的 IT 人员经过一定培训，就能够自己完 成一种新的工作流程的设置。 这对于不断变化的业务需求是一个很理想的解决方 案。* 不重新创造轮子框架对于大量典型场景给出了最优的实践。 在具体开发时， 与其无视前人的 成果，重新构思答案， 不如套用这些成熟、 稳定的做法。 这不仅能加快开发进度， 更能够提升系统的质量和健壮性。* 可维护性 / 知识共享 完全通过委托开发完成的系统很难由其他厂商维护。框架往往是多个企业、大量开发者实践的成果， 因此能

32、在一定程度上打破上述壁垒， 增进系统的可维护 性。当框架使用者形成社区之后，还能实现更高层次上的知识共享。缺点：* “太多 半成品总有其代价。 超市配好的一包菜里， 老是有我们用不到的调料但 是我们却不得不为之付费。同样，为了到达一般性和普适性，框架总比紧凑、贴 切的特定应用多出不少内容。 二次开发完成后， 企业获得的只是一种特定的实现， 却要为所有的客户化可能性付费， 为所有用不上的功能付费。 这是一个相当让人 为难的事实。* “太少框架总是一种限制。 就像半成品菜限制了我们的烹调方法， 框架也限制了我 们实际应用的可能性。 当框架本身设计的足够普适时， 我们不太会感到类似的限 制。但是，情

33、况往往正好相反面对一个足够特殊的需求， 二次开发者总有一 种冲破框架的渴望。最后的解决方法，往往是狡计、妥协和框架补丁的结合体。* 效率上面说过， 基于框架的系统中， 具体功能经常是通过配置实现的。 与硬编码hard-codec的方式相比拟，这虽然能提供很大的灵活性，但也往往牺牲了运 行时的效率。* 锁定一个采用特定框架的系统几乎肯定被锁定在这个厂商的产品上。 换言之，框 架意味着 all or nothing 式的态度，很难调和两种不同的框架，各取所长，更难把 应用系统从一个框架迁移到另一个这往往要求系统的全部改写。* 学习曲线一种框架也就是一种方言。 要精通特定框架的开发， 你要熟悉其中的

34、所有的 用法、思路和弱点。对于开发者，这也意味着比拟陡峭的学习曲线。3.2设计的原那么和评判标准对于如何判断一个软件的系统框架的优劣， 笔者认为，可以从以下几个方面 来评判：系统的内聚和耦合度。 这是保证一个系统的架构是否符合软件工程原那么 的首要标准。层次的清晰和简洁性。系统每个局部完成功能和目标必须是明确的，同 样的功能，应该只在一个地方实现。如果某个功能可以在系统不同的地 方实现，那么，将会给后来的开发和维护带来问题。 系统应该简单明了， 过于复杂的系统架构，会带来不必要的本钱和维护难度。在尽可能的情 况下，一个局部应该完成一个单独并且完整的功能。易于实现性。如果系统架构的实现非常困难，

35、甚至超出团队现有的技术 能力，那么，团队不得不花很多的精力用于架构的开发，这对于整个项 目来说，可能会得不偿失。可升级和可扩充性。一个系统框架，受设计时技术条件的限制，或者设 计者本人对系统认识的局限，可能不会考虑到今后所有的变化。但是， 系统必须为将来可能的变化做好准备，能够在今后，在目前已有的根底 上进行演进，但不会影响原有的应用。接口技术，是在这个方面普遍应 用的技巧。是否有利于团队合作开发。一个好的系统架构，不仅仅只是从技术的角 度来看，而且，它还应该适用于团队开发模型，可以方便一个开发团队 中各个不同角色的互相协作。例如，将Web 页面和业务逻辑组件分开，可是使页面设计人员和程序员的

36、工作分开来同步进行而不会互相影响。 性能。性能对于软件系统来说是很重要的，但是，有的时候，为了能让 系统得到更大的灵活性，可能不得不在性能和其他方面取得平衡。另外 一个方面，由于硬件技术的飞速开展和价格的下降，性能的问题往往可 以通过使用更好的硬件来获得提升。4、理想的框架4.1 基于 J2EE 的系统开发框架基于J2EE的企业级应用体系结构是拓展了当前的分布式 Web应用程序体系 结构的思想。它引入了组件技术、效劳技术和通信技术，依靠通信、效劳技术的 支持，系统通过访问效劳器端组件来完成系统的业务处理功能。 由效劳器端组件 来完成系统的业务处理功能。 随着软件工程技术的开展， 特别是面向对象

37、技术的 出现和应用，基于数据和行为封装的对象技术使基于组件技术的企业级应用体系 结构实现成为可能。 通过开发和扩展系统的中间件， 将不同的应用功能组件化使 多个应用程序使用一组共同的组件，简化系统结构，实现软件的复用。J2EE Java 2 platform enterprise edition 企业体系结构是 SUN 公司为了增强 Java在系统效劳器端的应用而推出的一个完整的基于Web应用系统的开发标准，是基于应用Java语言开发效劳器端EJB组件标准而开发出的能提供平台无关、 可移植、多用户、平安和标准的企业级 Java效劳器端部署平台。J2EE是通过一 个基于组件的应用程序模型为分布式

38、应用程序提供一个统一的开发标准和标准， 通过指定应用程序的功能和接口， 以及部署应用程序的运行环境， 提供了应用程 序与运行根底结构的明确分界线， 使应用程序开发人员可以集中考虑应用程序逻 辑和相关效劳。基于J2EE开发标准构造基于 Web的软件应用系统主要有以下优势：独立于系统平台：应用软件拥有Java的跨平台特性，增强了软件的适应 性； 集成企业信息资产：系统可以在企业已有的信息系统的根底上开发，并 可以使用其信息资源；系统开发效率高： J2EE 可以使开发人员使用中间件供应商提供的中间 件来负责通用的、复杂和繁琐的效劳器端任务，而主要开发业务处理组 件，提高了开发速度，适应不同企业软硬件

39、环境； 实现了软件复用：根据系统的要求，开发人员可以集成不同的已有组件 完成整个应用系统的开发； 可扩展性高：基于开发的应用程序可以部署到各种操作系统中；系统稳定性、持续性和平安性高：J2EE为应用系统提供了良好的平安和运行模型，系统可以稳定高效地运行。从本质上来讲， J2EE 是一大堆标准化的企业机效劳例如命名和目录服 务JNDI、为异构的事物性资源提供了标准事物管理接口JTS和JTA、连接遗留系统的标准机制JCA、资源池、线程管理等一一的集合体。EJB Enterprise JavaBear是经典的J2EE中的重要组成局部，它定义了编 写效劳器端组件的标准， 并提供了效劳器端组件和管理这些

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

41、 繁琐，没有为POJO助手类提供生命周期支持； 一旦开始把业务逻辑放在 EJB容器中，代码中参加很多EJB容器接口实 现，我们就很难替换它。如果有几个业务对象需要完成的任务是 EJB编 程模型禁止的，如创立线程、开启网络连接、读取文件、调用第三方API、或者是调用本地代码等，那就会出现问题；技术复杂，开发本钱高。针对EJB构架的如上缺点，目前比拟流行的一个解决方案是采用“轻量级容器构架构建J2EE系统。下面是基于“轻量级容器的 J2EE系统一一Appfuse框架结构图。持久层务层持 久 层业 务 层HttpBrowerHttpResponse1 ZRequestJSPreadsActio nS

42、ervletii4Struts-con fig.xmliiActio nFormj Action图2 Appfuse的三层体系结构4.2 基于框架技术的实现框架是指一个特定领域中的一组相互协作的类， 它是特定领域软件系统可以 复用的设计和局部实现。该特定领域软件的开发人员能够运用继承、合成等方法 定制和复用框架，开发特定的软件系统。可以说框架的复用是软件生产中最有效 的复用方式之一，能尽可能地复用已有的比拟成熟的应用框架也是最经济的开发 模式。Web应用框架是一种面向 Web应用领域的框架。当前在开放源代码运动的 推动下，基于J2EE体系的Web应用领域应用框架层出不穷，其中不乏优秀的 设计，

43、如基于MVC模式的Struts、处理持久层的Hibernate以及效劳于所有层 面的Spring等等。由于各种应用框架数目繁多，且没有公认的最好框架，因此 如何更好地复用它们就成为我们面临的问题。大局部Web应用在职责上一般分为三层：表示层，处理用户请求，数据信 息格式化。它通常由 Web容器运行，包括JSP、Servlet等组件；业务层，处理 与领域相关的具体业务逻辑，事物管理等；持久层，处理业务对象的持久化问题， 通常与数据库相关。以下图是我们设计的基于三层分类的Web应用框架整合模型图。上图中的模型根本思想是基于应用分层框架模式的， 用户可以根据实际应用 需求，选择相应层次如表示层、业务

44、层、持久层的最适合框架，将它们整合， 形成一个更高层次的框架。特别地，我们在传统的三层构架模式根底上，增加了 两个中间层，即效劳定位层和数据接口层，这样做的好处是可以进一步降低层次 间的耦合度。下面我们具体分析Web应用框架整合模型图的特点：1采用设计模式，有效地对层关系进行解耦所谓解耦就是降低耦合度。我们希望对框架进行整合后能得到一个具有好的 开放性和灵活性的框架模型，这就要求所得到的框架模型的各个层面的子框架间 能做到松散耦合，这样在实际应用中，可以根据需要很容易地替换掉某个层面的 子框架而不影响其它层面。这一目标的实现关键就是子框架间的解耦问题， 设计 模式提供了一个好的解决方法。设计模

45、式是针对反复出现的设计问题给出的、 经 过实践检验的、可复用的解决方案。通常，设计模式与领域无关，可用于不同的 应用系统和不同的领域， 它记录了现有的、 专家的设计知识， 可以用来为具体的 设计问题提供适当的解决方法； 而框架是一种可复用的、 可适配的软件， 它要有 灵活的结构以易于扩展。 框架中通常可能包含假设干个设计模式， 而设计模式比 框架具有更高的抽象性和更好的通用性。 可见，设计模式和框架二者既有联系又 有区别，正因如此，在我们的模型中，可以将设计模式方法深化到框架整合中， 从而有效地对持久层子框架和业务层子框架、表示层子框架和业务层子框架解 耦，使得各个层面间子框架之间松散耦合。持

46、久层子框架和业务层子框架解耦 为了对持久层子框架和业务层子框架解耦， 整合模型中采用了 J2EE 设计模 式中的数据访问对象模式 (DAO) ，在持久层子框架和业务层子框架间增加了数据 接口层。 DAO 模式通过接口和实现别离的方式，完全向上层隐藏了数据源实现 细节。当低层数据源实现变化时， DAO 向客户端提供的接口不会变化，所以该 模式允许DAO调整到不同的存储模式，而不会影响其上层。重要的是，DAO充 当了业务层和数据源之间的适配器， 将低级别的数据访问逻辑与高级别的业务逻 辑别离。因此通过在业务层子框架和持久层子框架间增加了数据接口层， 能有效 地降低两者的耦合度。表示层子框架和业务层

47、子框架解耦 为了降低表示层子框架和业务层子框架间的耦合度， 整合模型采用 J2EE 另 一个常用模式一一Manager模式，提供了一个通用的效劳定位层。效劳定位器模 式中有一个对象即效劳定位器知道如何获得一个应用程序所需的所有效劳。 整合模型中表示层子框架需要请求业务层子框架效劳时， 将向效劳定位器层发出 请求，间接获取相应的业务效劳对象接口， 而不是直接向业务层请求。 整合模型 提供的这个效劳定位层是与特定框架无关的， 它根据 XML 配置文件里定义的服 务映射关系来寻找表示层所需的业务效劳对象， 从而降低了业务层子框架和持久 层子框架间的耦合度。 2引入一组编程约束，解决功能冗余问题Web

48、 应用框架有的是针对多层次的，甚至是所有层次的，如 Spring 框架。 但是仅仅选用其特定层面的功能， 这时功能冗余问题就出现了。 我们的整合模型 针对应用于各个层次的子框架， 提出了一组约束， 将某个特定的框架功能限定于特定的层次，这样可以有效解决功能冗余问题。我们提出的约束如下： 针对表示层子框架的约束一个典型的 Web 应用的末端应该是表示层。我们规定表示层子框架的主要 功能有：管理用户的请求，作出相应的响应；为显示提供一个模型。而不该在表 示层子框架实例化编码中出现的， 与表示层无关的局部， 作出不可以出现的约束。 不可以出现在表示层子框架中的有：直接地与数据库通信，例如 JDBC

49、调用； 与应用程序相关联的业务逻辑以及校验；事务管理。如果不作出这些约束规定， 在表示层框架编码中引入这些代码，那么会带来高耦合和麻烦的维护。针对业务层子框架的约束我们规定可以在业务层子框架中出现的主要功能有： 处理应用程序的业务逻 辑和业务校验； 管理事务； 允许与其它层相互作用的接口； 管理业务层级别的对 象依赖；管理程序的执行从业务层到持久层 。针对持久层子框架的约束可以在持久层子框架中出现的主要功能有： 查询对象的相关信息语句； 如何 存储、更新、删除数据库记录； 支持大局部主流数据库， 并且支持 Parent/Child 关 系，事务处理，继承和多态。 3引入域对象层，能有效地解决框

50、架通信问题在框架整合过程中， 层间框架通信问题也是一个难以解决的常见问题。 为了 有效解决框架通信问题，我们的 WAFC 模型引入了域模块层，域模块层由实际 需求中的业务对象组成， 它为联系各个层面提供了一个纽带， 有了域模块层， 业 务领域对象信息就能够在层间进行传递，我们仅需关注域对象即可。根据以上的 Web 应用框架整合模型图结构及其特点分析，我们研究了目前 比拟优秀的开源框架工程， 并整合了优秀的框架， 作为飞机制造质量管理系统的 开发平台。表现层客户端业务层/浏览器持久层Hiber nate 框架数据接口层XML映射Hibernate配置文件|数据接口对象二 数据接口对象数据接口对象

51、数据库图4基于开源框架集成的信息管理系统软件平台F面我们具体描述该平台的实现技术及集成技术:1域对象层域对象层是连接各层的纽带，首先要创立域对象 (即域对象层中的对象)并且 确认域对象中哪些是需要持久化的，哪些是提供应业务层的，哪些是显示接口设计的。这层是编码的开始，也就是Model包中的模型文件。域对象是由简单Java 对象POJO编写的，因此具有良好的重用性和可扩展性。2业务层业务层处于整个Web应用的中心，负责业务对象的管理和维护。传统的J2EE 应用中，业务层对象的管理容器一般是 EJB容器，EJB容器提供了一个定义良好 的效劳层，然而却是一个重量级的框架：访问EJB组件相当困难，且需

52、要它本身的根底设施，这都让客户端变得复杂；无法轻松的在容器外对EJB进行配置；无法管理细粒度对象如 DAO组件，因此，我们需要一个轻量级的业务组件 管理容器替代它。业务框架选择的一个重要原那么是要防止业务应用代码对容器的依赖，这种功能就是所谓的控制反转(Inverse of Control, loC)。loC的实现有两种方式，依赖查找(Depe nde ncy Lookup)和依赖注入 (Dependency Injection)。EJB容器采用的就是前者实现方法，容器提供回调接口 和上下文环境给组件，组件自己使用容器提供的 API 查找资源和协作对象，容 器给用户提供的是一种入侵式的管理，

53、因此造成以上所说的缺乏。 依赖注入是让 容器去全权负责依赖查找，受管对象只需要暴露JavaBean的setter方法或者带参 数的构造子， 使容器可以在初始化时组装对象的依赖关系。 这种控制反转的方式 使得依赖的查找定位操作与应用代码完全无关，不依赖容器的API，不需要特殊 的接口这也就是轻量级容器与重量级容器的主要区别。Spring框架是轻量级容器的一个优秀代表，具有很强大的Bean管理能力，因此，我们采用 Spring 作为业务层的框架，用一个业务效劳对象接收一个数据 接口层的数据访问接口对象，用它来控制域对象层对象的持久化。 3表示层Struts是Apache软件基金下Jakarta工程

54、的一局部， 是目前Java Web MVC 框架中不争的王者。经过长达五年的开展，Struts已经逐渐成长为一个稳定、成熟的框架，并且占有了 MVC 框架中最大的市场份额，因此，我们在整合框架中 使用Struts作为Web应用的表现层。struts框架是MVC模式的经典表达：视图View：主要由JSP建立，struts自身包含了一组可扩展的自定义 标签库TagLib，可以简化创立用户界面的过程。目前标签库中包括： Bean标签，HTML标签，Logic标签，Nested标签，Template标签等。 模型Model：模型主要是表示一个系统的状态。在 Struts中，系统的 状态主要有 Acti

55、omForm Bean 表达，一般情况下，这些状态是非持久性 的。控制器Controller：在Struts框架中，控制器主要是 ActionServlet，但 是对于业务逻辑的操作那么主要由 Action、 ActionMapping、 ActionForward 这几个组件协调完成也许这几个组件，应该划分到模型中的业务逻辑 一块。其中， Action 扮演了真正的业务逻辑的实现者， 而 ActionMapping 和 ActionForward 那么指定了不同业务逻辑或流程的运行方向。由于 Struts 本身不提供中间层解决方案，它经常通过硬编码与中间层Singleton组合使用，或者是和

56、由JNDI查找的无状态SessionBear一起使用。假 设一个应用程序有许多业务对象和数据访问对象， 再加上相关联的资源， 并使用 上述方式将这些对象进行硬组装， 那么，缺少可插拔性将使组件的独立单元测试 非常难做到， 每个业务对象必须实现它自己的初始化， 可能需要访问共享配置持 有的单例。Struts与Spring集成的一个最简单方法是在容器中实现 Struts Action的组装， 即Struts Action作为Bean在应用上下文中定义，再通过一些自定义的工厂机制 从Struts配置文件中取得这些 Action的引用。这种方法要求对每个 Action进行 两次定义：一次是在 stru

57、ts-config.xml 文件中，一次是在 Spring 的上下文 XML 文件中，但是由于 Struts Action 不是可重用的通用对象， 因此将它们寄宿在 Spring 容器中并不理想。 各层次之间的分隔应该简明而清晰： 中间层对象寄宿在 Spring 容器中，Web组件在Struts的ActionServlet之中，web组件应该可以知道中间层 对象的存在，而中间层的对象不应该知道Web组件的存在。为此，我们用一个通用的工厂来负责所有业务对象的配置和装载， 取代这种 紧耦合的业务对象。 Spring 根应用上下文的查找可以被封装在一个简单的基类 (BaseAction)中，至于具体的实现，既可以向Struts Action暴露应用上下文，也可 以暴露从应用上下文取来的特定对象。 下面是Struts的BaseAction中的局部代码：private WebApplicationContext ctx = null;public Object getBean(String name) if (ctx = null) ctx = WebApplicationContextUtils.getRequire