《开发框架的选择》由会员分享，可在线阅读，更多相关《开发框架的选择（33页珍藏版）》请在金锄头文库上搜索。
1、软件开发框架的运用和选择如何在企业业务迅猛发展、应用需求不断扩大、市场竞争日趋激烈、业务整合难度不断加大的基础上，采用灵活、先进的设计理念及结合开放式的系统软硬件平台，在确保业务系统安全、高效、可靠的基础上，构建一个完全满足企业信息化要求，同时在面向 Web、事务调度、系统配置、业务拓展、统计分析方面表现优异的企业应用，是企业信息化中必须面对的重要问题。由于软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识、内容、问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，它可以处理系统的很多细节
2、问题，比如，事物处理、安全性、数据流控制等问题。还有，框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。声明：本文是将网络上比较优秀的文章进行了整理和组合，旨在部门内部进行讨论，不要进行传播，以免引起不必要的争议。1、 需要说明的几个概念人们总是偏爱炒作概念。一个表达方式，如果听起来足够响亮，写在纸上能够吸引眼球，那就会变成很多人的新宠。但同样是这些概念，经过太多人的传递、消费之后，原本的含义反而像硬币上的图案一样被磨损殆尽：几乎没有人知道这些说法到底是指什么了。在 IT 业界， “平台（platform） ”、 “框架（fra
3、mework） ”、 “构架（ architecture） ”等等就是这种人见人爱的概念。几乎每个厂商都愿意请来其中的一位、甚至多位为自己推销。久而久之，这些说法似乎适用于各个领域、各个层面：所有的软件系统都是“平台” ，所有的开发者都在沉迷于独有的“框架” 。原本有确切意义的“好词” ，经过这一番争夺和滥用，也只能衰减为所谓的“buzzwords ”，供市场营销人士们玩味了。(理解企业应用框架 选择自 kxiangli 的 Blog)1.1 框架软件业圣经设计模式对框架有如下定义：“A framework is a set of cooperating classes that make u
4、p a reusable design for a specific class of software（一个框架，就是一组相互协作的类；对于特定的一类软件，框架构成了一种可重用的设计） ”。这个定义虽然主要着眼于面向对象的软件开发，但已经基本上给出了这个词的核心含义：框架是软件系统的设计、开发过程中的一个概念，它强调对已完成的设计、代码的重复使用，并且，一个框架主要适用于实现某一特定类型的软件系统。为了更好地说明框架是什么，也许还应该看看框架不是什么。 框架不是现成可用的应用系统。它仍是一个半成品，等待后来者做“二次开发” ，实现为具体的应用系统。 框架不是“平台” 。后者的概念更加浮泛和模
5、糊人们说的一个平台，可以是一种操作系统，一种应用服务器，一种数据库软件，一种通信中间件等等，因此“平台”几乎成了所有系统软件的统称。在平台的大家族中，框架的概念可能与近来人们常说的“应用平台”最为接近，但平台主要指提供特定服务的系统软件，而框架则更侧重于设计、开发过程，或者可以说，框架通过调用平台提供的服务而起作用。 框架不是工具包（toolkit）/类库（library）/API 。目前流行的很多框架中，就包括了大量的类库和 API，但是调用 API 并不就是在使用框架开发。仅仅使用 API 时，开发者完成系统的主体部分，并不时地调用类库实现特定任务。而框架构成了通用的、具有一般性的系统主体
6、部分， “二次开发者”只是像做填空题一样，根据具体业务，完成特定应用系统中与众不同特殊的部分。 框架不是构架（architecture） 。构架确定了系统整体结构、层次划分、不同部分之间的协作等设计考虑。框架比构架更具体，更偏重于技术实现。确定框架后，构架也随之确定，而对于同一种构架（比如 web开发中的 MVC） ，可以通过多种框架（比如 Apache Struts 或WebWork）实现。(理解企业应用框架 选择自 kxiangli 的 Blog)如何最大程度地萃取不同企业应用系统的共性，重复使用已经完成的设计和代码，对企业应用系统中典型场景给出最佳解决方案这是一个“一般性”的问题；如何让
7、一个早先完成的软件产品贴切地适应极为多变、复杂的企业需求这是一个“特殊性”的问题。作为对这一组冲突的一种解决方案，不少厂商推出了自己的企业应用框架。这些框架往往是从大量的委托项目开发中精选出的系统“不变项” ，因此具有很强的普适性和实用性。目前，主流企业应用框架中大都包含对以下问题的现成解决方案： 持久性（persistence ）：实现数据存储、处理，数据与对象映射，数据缓存（caching） 。 事务（transaction ）：确保一组关联操作正常、完整的执行。 安全性（security）：保证系统的通信安全、数据安全。 负载均衡（load balance ）：在大量并发访问时，保持系统
8、可用。 监控（system monitoring/management）：监控系统运行状况，设置系统参数。 日志（logging）：记录系统运行情况和异常，记录特定用户操作。 应用集成 （application integration）：与其他系统、应用程序集成。 认证/权限/组织角色管理（authentication/authorization）：管理系统用户、组织职权结构，限制特定用户对特定功能、特定数据的访问。 业务模型（domain model）：管理系统中业务对象的属性、字段。 业务逻辑（business logic/rules）：实现业务规则和业务逻辑。 工作流（work flow
9、）：实现多用户、多环节之间的业务处理流程。 文件管理（file management）：管理文档，实现系统内部的文件传递。 报表/打印 （reporting/printing）：实现数据打印，实现报表的定制和输出。 门户/信息发布 （portal solution）：发布企业相关的信息、新闻，提供企业客户的访问入口。 通信（communication/messaging）：系统内部的消息、通知；系统与外部角色（比如企业客户）之间通过不同通信媒介（电话、网站、邮件等）的互动。 特定行业/领域模块 （business modules）：实现特定行业、流域相关的业务模块。以上诸方面中，除了前四项目前
10、主要由应用服务器解决之外，其他的部分本身都是专门的软件开发领域。框架的作用，在于确定上述每种因素的具体技术实现，并规定它们在系统中的组织方式和协作方式，从而给出完整的企业应用解决方案。1.2 架构软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口(计算机科学)来实现。一般而言，架构有两个要素：它是一
11、个软件系统从整体到部分的最高层次的划分。一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。详细地说，就是要包括架构元件（Architecture Component） 、联结器（Connector） 、任务流（Task-flow） 。所谓架构元件，也就是组成系统的核心 砖瓦 ，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。下图就是一个软件系统的逻辑架构图：图 1建造一个系统所做出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定
12、需要事先做出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。1.3 区别与联系首先，软件的架构是高层次的全局理念，而框架是逐步加强固化和粘滞的（不可否认，它们也可能有灵活性的） ，使用固化和粘滞的物件来实现相对灵活的设计是不恰当的做法。而通常，架构所包含的根据实际情况所作的取舍选择，有业务架构的倾向，这个倾向包含了系统解耦合的力度和关键实现的技术选择，这个超出了框架的适用范畴。也存在试图包罗万象的框架，但通常这不是好的选择，如果考虑到系统复杂程度所带来的损害更加如此。但框架可以组合成为软件架
13、构，但最好要在强大、灵活和简单之间做出平衡，而这个平衡绝对是重要的。单纯的组合若干优秀的框架或者基础件/类而不考虑适度的取舍变化的架构设计，通常只能够算是技术的“表演” ，这是不恰当的。2、 软件重用及组件技术尽管当前社会的信息化过程对软件需求的增长非常迅速，但目前软件的开发与生产能力却相对不足，这不仅造成许多急需的软件迟迟不能被开发出来，而且形成了软件脱节现象。自 20 世纪 60 年代人们认识到软件危机，并提出软件工程以来，已经对软件开发问题进行了不懈地研究。近年来人们认识到，要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。这包括技术和管理两方面的问题：在
14、技术上，应该采用基于重用的软件生产技术；在管理上，应该采用多维的工程管理模式。随着软件技术的发展，软件重用已经从模块、对象的重用发展到了基于组件的重用和基于框架的重用，这也是当前最主要的两种软件重用的方式。2.1 基于组件技术的软件重用近年来人们认识到，要真正解决软件危机，实现软件的工业化生产是唯一可行的途径。分析传统工业及计算机硬件产业成功的模式可以发现，这些工业的发展模式均是符合标准的零部件/组件生产以及基于标准组件的产品生产，其中，组件是核心和基础。一般认为，组件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辨识的系统；结构上，它是语义描述、通信接口和实现代码的
15、复合体。简单地说，组件是具有一定的功能，能够独立工作或能同其他组件装配起来协调工作的程序体，组件的使用同它的开发、生产无关。从抽象程度来看，面向对象技术以达到类级重用（代码重用） ，它以类为封装的单位。这样的重用粒度还太小，不足以解决异构互操作和效率更高地重用。组件将抽象的程度提高一个更高的层次，它是对一组类的组合进行封装，并代表完成一个或多个功能的特定服务，也为用户提供了多个接口。整个组件隐藏了具体的实现，只用接口对外提供服务。组件模型是对组件本质特征的抽象描述。目前，国际上已经形成了许多组件模型，这些模型的目标和作用各不相同，其中部分模型属于参考模型（例如3C 模型） ，部分模型属于描述模
16、型（例如 RESOLVE 模型和 REBOOT 模型） 。还有一部分模型属于实现模型。近年来，已形成三个主要流派，分别是OMG（ Object Management Group，对象管理集团）的 CORBA（Common Object Request Broker Architecture，通用对象请求代理结构） 、Sun 的 EJB（Enterprise Java Bean）和 Microsoft 的 DCOM（Distributed Component Object Model，分布式组件对象模型） ，这些实现模型将组建的接口和实现进行了有效的分离，提供了组件交互能力，从而增加了重用的机会，并适应了目前网络环境下大型软件系统的要求。在组件库管理系统方面。美国军方与政府资助的项目监理了组件库系统如 CARDS、ASSET、DSRS 等。基于开放体系结构，STARS 项目就组件库之间共享资源和无缝互操作问题，提交了 ALOAF（Asset Librar
