开发框架的选择.docx
《开发框架的选择.docx》由会员分享，可在线阅读，更多相关《开发框架的选择.docx（34页珍藏版）》请在冰豆网上搜索。
开发框架的选择
软件开发框架的运用和选择
如何在企业业务迅猛发展、应用需求不断扩大、市场竞争日趋激烈、业务整合难度不断加大的基础上，采用灵活、先进的设计理念及结合开放式的系统软硬件平台，在确保业务系统安全、高效、可靠的基础上，构建一个完全满足企业信息化要求，同时在面向Web、事务调度、系统配置、业务拓展、统计分析方面表现优异的企业应用，是企业信息化中必须面对的重要问题。
由于软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识、内容、问题太多。
在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。
而且框架一般是成熟，稳健的，它可以处理系统的很多细节问题，比如，事物处理、安全性、数据流控制等问题。
还有，框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。
声明：
本文是将网络上比较优秀的文章进行了整理和组合，旨在部门内部进行讨论，不要进行传播，以免引起不必要的争议。
1、需要说明的几个概念
人们总是偏爱炒作概念。
一个表达方式，如果听起来足够响亮，写在纸上能够吸引眼球，那就会变成很多人的新宠。
但同样是这些概念，经过太多人的传递、消费之后，原本的含义反而像硬币上的图案一样被磨损殆尽：
几乎没有人知道这些说法到底是指什么了。
在IT业界，“平台（platform）”、“框架（framework）”、“构架（architecture）”等等就是这种人见人爱的概念。
几乎每个厂商都愿意请来其中的一位、甚至多位为自己推销。
久而久之，这些说法似乎适用于各个领域、各个层面：
所有的软件系统都是“平台”，所有的开发者都在沉迷于独有的“框架”。
原本有确切意义的“好词”，经过这一番争夺和滥用，也只能衰减为所谓的“buzzwords”，供市场营销人士们玩味了。
（理解企业应用框架 选择自kxiangli的Blog）
1.1框架
软件业圣经《设计模式》对框架有如下定义：
“Aframeworkisasetofcooperatingclassesthatmakeupareusabledesignforaspecificclassofsoftware（一个框架，就是一组相互协作的类；对于特定的一类软件，框架构成了一种可重用的设计）”。
这个定义虽然主要着眼于面向对象的软件开发，但已经基本上给出了这个词的核心含义：
框架是软件系统的设计、开发过程中的一个概念，它强调对已完成的设计、代码的重复使用，并且，一个框架主要适用于实现某一特定类型的软件系统。
为了更好地说明框架是什么，也许还应该看看框架不是什么。
●框架不是现成可用的应用系统。
它仍是一个半成品，等待后来者做“二次开发”，实现为具体的应用系统。
●框架不是“平台”。
后者的概念更加浮泛和模糊——人们说的一个平台，可以是一种操作系统，一种应用服务器，一种数据库软件，一种通信中间件等等，因此“平台”几乎成了所有系统软件的统称。
在平台的大家族中，框架的概念可能与近来人们常说的“应用平台”最为接近，但平台主要指提供特定服务的系统软件，而框架则更侧重于设计、开发过程，或者可以说，框架通过调用平台提供的服务而起作用。
●框架不是工具包（toolkit）/类库（library）/API。
目前流行的很多框架中，就包括了大量的类库和API，但是调用API并不就是在使用框架开发。
仅仅使用API时，开发者完成系统的主体部分，并不时地调用类库实现特定任务。
而框架构成了通用的、具有一般性的系统主体部分，“二次开发者”只是像做填空题一样，根据具体业务，完成特定应用系统中与众不同特殊的部分。
●框架不是构架（architecture）。
构架确定了系统整体结构、层次划分、不同部分之间的协作等设计考虑。
框架比构架更具体，更偏重于技术实现。
确定框架后，构架也随之确定，而对于同一种构架（比如web开发中的MVC），可以通过多种框架（比如ApacheStruts或WebWork）实现。
（理解企业应用框架 选择自kxiangli的Blog）
如何最大程度地萃取不同企业应用系统的共性，重复使用已经完成的设计和代码，对企业应用系统中典型场景给出最佳解决方案——这是一个“一般性”的问题；如何让一个早先完成的软件产品贴切地适应极为多变、复杂的企业需求——这是一个“特殊性”的问题。
作为对这一组冲突的一种解决方案，不少厂商推出了自己的企业应用框架。
这些框架往往是从大量的委托项目开发中精选出的系统“不变项”，因此具有很强的普适性和实用性。
目前，主流企业应用框架中大都包含对以下问题的现成解决方案：
●持久性（persistence）：
实现数据存储、处理，数据与对象映射，数据缓存（caching）。
●事务（transaction）：
确保一组关联操作正常、完整的执行。
●安全性（security）：
保证系统的通信安全、数据安全。
●负载均衡（loadbalance）：
在大量并发访问时，保持系统可用。
●监控（systemmonitoring/management）：
监控系统运行状况，设置系统参数。
●日志（logging）：
记录系统运行情况和异常，记录特定用户操作。
●应用集成（applicationintegration）：
与其他系统、应用程序集成。
●认证/权限/组织角色管理（authentication/authorization）：
管理系统用户、组织职权结构，限制特定用户对特定功能、特定数据的访问。
●业务模型（domainmodel）：
管理系统中业务对象的属性、字段。
●业务逻辑（businesslogic/rules）：
实现业务规则和业务逻辑。
●工作流（workflow）：
实现多用户、多环节之间的业务处理流程。
●文件管理（filemanagement）：
管理文档，实现系统内部的文件传递。
●报表/打印（reporting/printing）：
实现数据打印，实现报表的定制和输出。
●门户/信息发布（portalsolution）：
发布企业相关的信息、新闻，提供企业客户的访问入口。
●通信（communication/messaging）：
系统内部的消息、通知；系统与外部角色（比如企业客户）之间通过不同通信媒介（电话、网站、邮件等）的互动。
●特定行业/领域模块（businessmodules）：
实现特定行业、流域相关的业务模块。
以上诸方面中，除了前四项目前主要由应用服务器解决之外，其他的部分本身都是专门的软件开发领域。
框架的作用，在于确定上述每种因素的具体技术实现，并规定它们在系统中的组织方式和协作方式，从而给出完整的企业应用解决方案。
1.2架构
软件架构（softwarearchitecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件架构描述的对象是直接构成系统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
在面向对象领域中，组件之间的连接通常用接口（计算机科学）来实现。
一般而言，架构有两个要素：
●它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（ArchitectureComponent）、联结器（Connector）、任务流（Task-flow）。
所谓架构元件，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
下图就是一个软件系统的逻辑架构图：
图1
●建造一个系统所做出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先做出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。
显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
1.3区别与联系
首先，软件的架构是高层次的全局理念，而框架是逐步加强固化和粘滞的（不可否认，它们也可能有灵活性的），使用固化和粘滞的物件来实现相对灵活的设计是不恰当的做法。
而通常，架构所包含的根据实际情况所作的取舍选择，有业务架构的倾向，这个倾向包含了系统解耦合的力度和关键实现的技术选择，这个超出了框架的适用范畴。
也存在试图包罗万象的框架，但通常这不是好的选择，如果考虑到系统复杂程度所带来的损害更加如此。
但框架可以组合成为软件架构，但最好要在强大、灵活和简单之间做出平衡，而这个平衡绝对是重要的。
单纯的组合若干优秀的框架或者基础件/类而不考虑适度的取舍变化的架构设计，通常只能够算是技术的“表演”，这是不恰当的。
2、软件重用及组件技术
尽管当前社会的信息化过程对软件需求的增长非常迅速，但目前软件的开发与生产能力却相对不足，这不仅造成许多急需的软件迟迟不能被开发出来，而且形成了软件脱节现象。
自20世纪60年代人们认识到软件危机，并提出软件工程以来，已经对软件开发问题进行了不懈地研究。
近年来人们认识到，要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。
这包括技术和管理两方面的问题：
在技术上，应该采用基于重用的软件生产技术；在管理上，应该采用多维的工程管理模式。
随着软件技术的发展，软件重用已经从模块、对象的重用发展到了基于组件的重用和基于框架的重用，这也是当前最主要的两种软件重用的方式。
2.1基于组件技术的软件重用
近年来人们认识到，要真正解决软件危机，实现软件的工业化生产是唯一可行的途径。
分析传统工业及计算机硬件产业成功的模式可以发现，这些工业的发展模式均是符合标准的零部件/组件生产以及基于标准组件的产品生产，其中，组件是核心和基础。
一般认为，组件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辨识的系统；结构上，它是语义描述、通信接口和实现代码的复合体。
简单地说，组件是具有一定的功能，能够独立工作或能同其他组件装配起来协调工作的程序体，组件的使用同它的开发、生产无关。
从抽象程度来看，面向对象技术以达到类级重用（代码重用），它以类为封装的单位。
这样的重用粒度还太小，不足以解决异构互操作和效率更高地重用。
组件将抽象的程度提高一个更高的层次，它是对一组类的组合进行封装，并代表完成一个或多个功能的特定服务，也为用户提供了多个接口。
整个组件隐藏了具体的实现，只用接口对外提供服务。
组件模型是对组件本质特征的抽象描述。
目前，国际上已经形成了许多组件模型，这些模型的目标和作用各不相同，其中部分模型属于参考模型（例如3C模型），部分模型属于描述模型（例如RESOLVE模型和REBOOT模型）。
还有一部分模型属于实现模型。
近年来，已形成三个主要流派，分别是OMG（ObjectManagementGroup，对象管理集团）的CORBA（CommonObjectRequestBrokerArchitecture，通用对象请求代理结构）、Sun的EJB（EnterpriseJavaBean）和Microsoft的DCOM（DistributedComponentObjectModel，分布式组件对象模型），这些实现模型将组建的接口和实现进行了有效的分离，提供了组件交互能力，从而增加了重用的机会，并适应了目前网络环境下大型软件系统的要求。
在组件库管理系统方面。
美国军方与政府资助的项目监理了组件库系统如CARDS、ASSET、DSRS等。
基于开放体系结构，STARS项目就组件库之间共享资源和无缝互操作问题，提交了ALOAF（AssetLibraryOpenArchitectureFramework，开放体系结构的组件库框架）1.2版本。
该框架体系给出了一个组件库架构的参考模型，实现了ALOAF规约作为该模型的实例，证明了以公共元素为基础，在组件库之间交换信息和创建易于移植的复用工具是可行的和必要的。
可复用库互操作组织（ReuseLibraryInteroperabilityGroup）提出了解决组件互操作方案BIDM和UDM，其中BIDM是UDM的子集，定义了实现互操作、复用库间交换软件组件所需的信息的最小集合。
组件软件设计的一些主要技术如下：
●组件标准接口技术
组件之间如何实现通讯是组件软件理论的重要的技术之一，这需要定义一套标准接口，组件间的互操作性要求接口统一；从软件复用的角度来讲，为了保证组件能够被其他应用系统重复利用，也需要实行统一的标准接口。
因此接口技术特征就代表了不同的组件模型标准。
接口技术包括了接口的定义和唯一标识、接口函数的调用、接口与对象的关系以及接口所具有的特性等。
这些都是每种接口规范必不可少的，组件的良好构造、相互间的集成都需要对接口进行严格地规范定义。
●组件库管理技术
组件软件技术的框架就是对现成的合适组件进行应用集成，随着组件的不断增加，为了便于对组件进行区分和识别，需要建立组件库加以管理。
组件库中可以包括购买的第三方开发的商业组件、完全自主开发的组件、或者经改造后的第三方开发的组件。
在软件工厂里，组件库的管理应该由高级人员来负责，如系统分析人员，因为在应用系统的设计中，系统分析员不仅需要对需求有清楚的了解，还需要多已有得各种组件功能了如指掌，这样有利于快速设计性能优良的软件框架。
组件库管理技术涉及到组件各种特性的标识、分类技术、登记办法、检索机制及其它相关处理等等。
组件库的管理对模块化的软件开发具有非常重要的意义，一个良好的组件库无疑会提高软件设计速度、增加软件应用系统的性能。
●组件的组装集成技术
组装技术也是一个相当重要的技术难题之一，尤其是软件组件的组装比生产车间里机械零部件的组装存在更多的兼容性、组建功能上的不完全匹配、运行在网络环境的各种组件状态、系统的稳定性分析、处于磨合期发生的症状等，这些都是组件软件系统集成中要解决的。
2.2基于框架技术的软件重用
从重用粒度上看，框架要比组件大。
框架重用是一种面向领域的软件重用方式。
框架一般建立在同一个或相似领域中，即所要开发的软件系统要具有较强的相似性，通过框架把领域中不变或易变的部分在一定时间间隔内固定下来，把易变的部分以用户接口的形式保留下来，从而达到设计和代码的重用。
框架技术与组件技术的结合产生了基于组件的应用框架技术，这是框架技术的一个发展趋势。
2.2.1框架的定义和描述
最早的对框架描述由Deutsch在1983年给出：
“多个抽象类和它们相关算法的集合可组成一个框架，该框架在特定应用中可以通过专用代码的添加将具体子类组织在一起运作。
框架由抽象类及其实现的操作和对具体子类的期望组成。
”
其他对框架有以下比较重要的定义和描述。
Johnson和Foot在1988年给出的定义：
框架是封装了特定应用族抽象设计的抽象类的几何，框架又是一个模板，关键的方法和其他细节在框架实例中实现。
Buschmann：
框架是一个可实例化的、部分完成的软件系统或子系统，定义了一组系统或子系统的体系结构并提供了构造系统的基本构造模块，还定义了对特殊功能实现所需要的调整方式。
在一个面向对象的环境中，框架由抽象类和具体类组成；框架的实例化包括现有类的实例化和衍生。
Johnson：
框架=模式+组件。
框架式开发人员定制的应用系统的骨架，使整个系统或子系统的可重用设计，由一组抽象组件和组件实例间的交互方式组成。
以上是对一般框架概念的描述，对应用框架的描述和定义主要有：
Gamma：
应用框架又称为通用应用，是为一个特定应用领域的软件系统提供可重用结构的一组相互协作的类的集合。
Buschmann：
特定领域应用的框架成为应用框架。
Froehlich：
应用框架就是某个领域公共问题的骨架式解决方案。
框架为该领域所有应用提供公共的体系结构和功能基础。
Batory：
应用框架技术适用于应用产品线的、通用的、面向对象的代码结构化技术。
一个框架就是表达抽象设计的抽象类的集合；框架实例就是为可执行子系统提供的抽象类的子集的具体类的集合。
框架是为了重用而设计的：
抽象类封装了公共代码，具体类封装特定实例的代码。
经过分析，可以得出以上众多对应用框架的描述的共同点是：
●应用框架解决的是一个领域或产品族的问题，规定了问题应该如何分解。
●包含了应用或子系统的设计，由一个相互协作的类或组件集合组成。
●可以通过继承或类的组合来创建应用。
框架技术的基本特征总结如下：
●反向控制：
类库是客户代码调用库中已存在类的方法，框架内嵌了控制流，框架调用客户代码——加入框架的新组件和抽象类的方法实例。
●可重用性：
框架提供了设计和代码的重用能力。
●扩展性：
为规划的变化提供了热点（hotspot）或钩子（hook）等显式说明方式。
●模块化或组件化：
框架由固定的、稳定的接口和封装的热点。
2.2.2框架的实现技术
一般框架有三种建立方式：
自顶向下、自底向上和混合方式。
前两种框架建立方式与建立全新的软件产品线时的演化方式十分类似，也具有相同的过程和优缺点。
混合方式指在大型应用框架的建立过程中，先将应用领域划分为不同的子区域，再分别解决，最终集成为一个完整框架的做法。
根据框架的使用和扩展方式，可以将框架分为两大类：
黑盒框架和白盒框架。
黑盒框架通过组件/类的组合来支持重用和扩展。
应用中的类由框架的不同组件组合而成。
在框架所在领域中，每个组件都有一个预定义的标准接口，一组共享相同接口但能满足不同应用需求的组件组成一个“插接兼容”的组件集合。
白盒框架一般使用类的集成机制实现，由未完成的类（抽象类）组成，类有一个或多个抽象接口或虚方法。
应用需要在抽象类的继承子类中提供特定意义的方法实例来重用框架。
开发者通过虚方法的实例化将特定应用的代码嵌入框架来生成应用，所以虚方法又成为“钩子”或“热点”。
白盒重用需要对框架有很好的理解，生成紧耦合系统。
黑盒重用不需要对框架的内部结构有太多的了解，产生松耦合系统。
具体的框架实际上都是“灰色”的，是可继承和可组合方式的结合。
灰色框架可以分成三部分：
固定的、可选择的和开放的。
框架的固定部分包含了该领域最基本的功能，内建了应用的控制流，有框架主干实现，对应着领域共用部分。
框架的可选择部分为该领域中相对固定的、应用特定的功能特征即领域个性部分，用可组合的类或组件实现，在应用构造时在这些组件或类中进行选择、组合。
对一些无法准确估计和预测的功能特征即框架的开放部分，只能为其规定统一的接口和与框架的挂接点，用可继承的抽象类的方法来实现，这些部分可以根据应用的具体需求变化进行单独的调整。
与体系结构的层次类似，框架也可设计为层次结构，可称之为层次框架。
例如把一个完整的框架划分为：
应用框架、领域框架、支撑框架多个层次，框架层次间是标准的或统一的接口。
层次框架与层次体系结构具有相同的优点。
框架其实就是一组组件，供你选用完成你自己的系统。
简单说就是使用别人搭好的舞台，你来做表演。
而且，框架一般是成熟的，不断升级的软件。
可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文（Context）关系。
因此构件库的大规模重用也需要框架。
构件领域框架方法在很大程度上借鉴了硬件技术发展的成就，它是构件技术、软件体系结构研究和应用软件开发三者发展结合的产物。
在很多情况下，框架通常以构件库的形式出现，但构件库只是框架的一个重要部分。
框架的关键还在于框架内对象间的交互模式和控制流模式。
框架比构件可定制性强。
在某种程度上，将构件和框架看成两个不同但彼此协作的技术或许更好。
框架为构件提供重用的环境，为构件处理错误、交换数据及激活操作提供了标准的方法。
应用框架的概念也很简单。
它并不是包含构件应用程序的小片程序，而是实现了某应用领域通用完备功能（除去特殊应用的部分）的底层服务。
使用这种框架的编程人员可以在一个通用功能已经实现的基础上开始具体的系统开发。
框架提供了所有应用期望的默认行为的类集合。
具体的应用通过重写子类（该子类属于框架的默认行为）或组装对象来支持应用专用的行为。
应用框架强调的是软件的设计重用性和系统的可扩充性,以缩短大型应用软件系统的开发周期，提高开发质量。
与传统的基于类库的面向对象重用技术比较，应用框架更注重于面向专业领域的软件重用。
应用框架具有领域相关性，构件根据框架进行复合而生成可运行的系统。
框架的力度越大，其中包含的领域知识就更加完整。
3、开发框架的意义和选取原则
3.1开发框架的意义
企业应用框架是菜场里的半成品。
当我们面对要么自己下厨、要么去饭馆吃饭的选择时，我们往往会采取这种省时省力的折衷方案。
但是选择之所以为选择，就因为其中肯定包含对收益和代价的权衡，都隐含着复杂的利弊关系（优点和缺点）。
下面我们也来讨论一下企业应用框架的情况：
优点：
*缩短开发周期
毫无疑问，采用框架的开发，要比一切从头做起快速、高效得多。
通过一般化（generalization）和重用（reuse）机制，框架能最大限度地加快一个特定应用系统的实现。
*客户化
如上所述，基于框架的系统有很多功能通过配置而不是编程实现，这样也给用户带来了一定便利。
比如，企业内部的IT人员经过一定培训，就能够自己完成一种新的工作流程的设置。
这对于不断变化的业务需求是一个很理想的解决方案。
*不重新发明轮子
框架对于大量典型场景给出了最优的实践。
在具体开发时，与其无视前人的成果，重新构思答案，不如套用这些成熟、稳定的做法。
这不仅能加快开发进度，更能够提升系统的质量和健壮性。
*可维护性/知识共享
完全通过委托开发完成的系统很难由其他厂商维护。
框架往往是多个企业、大量开发者实践的成果，因此能在一定程度上打破上述壁垒，增进系统的可维护性。
当框架使用者形成社区之后，还能实现更高层次上的知识共享。
缺点：
*“太多”
半成品总有其代价。
超市配好的一包菜里，老是有我们用不到的调料——但是我们却不得不为之付费。
同样，为了达到一般性和普适性，框架总比紧凑、贴切的特定应用多出不少内容。
二次开发完成后，企业获得的只是一种特定的实现，却要为所有的客户化可能性付费，为所有用不上的功能付费。
这是一个相当让人尴尬的事实。
*“太少”
框架总是一种限制。
就像半成品菜限制了我们的烹调方法，框架也限制了我们实际应用的可能性。
当框架本身设计的足够普适时，我们不太会感到类似的限制。
但是，情况往往正好相反——面对一个足够特殊的需求，二次开发者总有一种冲破框架的渴望。
最后的解决办法，往往是狡计、妥协和框架补丁的结合体。
*效率
上面说过，基于框架的系统中，具体功能经常是通过配置实现的。
与硬编码（hard-coded）的方式相比较，这虽然能提供很大的灵活性，但也往往牺牲了运行时的效率。
*锁定
一个采用特定框架的系统几乎肯定被锁定在这个厂商的产品上。
换言之，框架意味着allornothing式的态度，很难调和两种不同的框架，各取所长，更难把应用系统从一个框架迁移到另一个——这往往要求系统的全部改写。
*学习曲线
一种框架也就是一种方言。
要精通特定框架的开发，你要熟悉其中的所有的用法、思路和弱点。
对于开发者，这也意味着比较陡峭的学习曲线。
3.2设计的原则和评判标准
对于如何判断一个软件的系统框架的优劣，笔者认为，可以从以下几个方面来评判：
●系统的内聚和耦合度。
这是保证一个系统的架构是否
升级会员 