开发框的选择.docVIP

软件开发框架的运用和选择 如何在企业业务迅猛发展、应用需求不断扩大、市场竞争日趋激烈、业务整合难度不断加大的基础上，采用灵活、先进的设计理念及结合开放式的系统软硬件平台，在确保业务系统安全、高效、可靠的基础上，构建一个完全满足企业信息化要求，同时在面向Web、事务调度、系统配置、业务拓展、统计分析方面表现优异的企业应用，是企业信息化中必须面对的重要问题。 由于软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识、内容、问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，它可以处理系统的很多细节问题，比如，事物处理、安全性、数据流控制等问题。还有，框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。 声明：本文是将网络上比较优秀的文章进行了整理和组合，旨在部门内部进行讨论，不要进行传播，以免引起不必要的争议。 需要说明的几个概念 人们总是偏爱炒作概念。一个表达方式，如果听起来足够响亮，写在纸上能够吸引眼球，那就会变成很多人的新宠。但同样是这些概念，经过太多人的传递、消费之后，原本的含义反而像硬币上的图案一样被磨损殆尽：几乎没有人知道这些说法到底是指什么了。在IT业界，“平台（platform）”、“框架（framework）”、“构架（architecture）”等等就是这种人见人爱的概念。几乎每个厂商都愿意请来其中的一位、甚至多位为自己推销。久而久之，这些说法似乎适用于各个领域、各个层面：所有的软件系统都是“平台”，所有的开发者都在沉迷于独有的“框架”。原本有确切意义的“好词”，经过这一番争夺和滥用，也只能衰减为所谓的“buzzwords”，供市场营销人士们玩味了。(理解企业应用框架? 选择自 HYPERLINK /user/kxiangli kxiangli 的 Blog) 框架 软件业圣经《设计模式》对框架有如下定义：“A framework is a set of cooperating classes that make up a reusable design for a specific class of software（一个框架，就是一组相互协作的类；对于特定的一类软件，框架构成了一种可重用的设计）”。这个定义虽然主要着眼于面向对象的软件开发，但已经基本上给出了这个词的核心含义：框架是软件系统的设计、开发过程中的一个概念，它强调对已完成的设计、代码的重复使用，并且，一个框架主要适用于实现某一特定类型的软件系统。 为了更好地说明框架是什么，也许还应该看看框架不是什么。 框架不是现成可用的应用系统。它仍是一个半成品，等待后来者做“二次开发”，实现为具体的应用系统。 框架不是“平台”。后者的概念更加浮泛和模糊——人们说的一个平台，可以是一种操作系统，一种应用服务器，一种数据库软件，一种通信中间件等等，因此“平台”几乎成了所有系统软件的统称。在平台的大家族中，框架的概念可能与近来人们常说的“应用平台”最为接近，但平台主要指提供特定服务的系统软件，而框架则更侧重于设计、开发过程，或者可以说，框架通过调用平台提供的服务而起作用。 框架不是工具包（toolkit）/类库（library）/API。目前流行的很多框架中，就包括了大量的类库和API，但是调用API并不就是在使用框架开发。仅仅使用API时，开发者完成系统的主体部分，并不时地调用类库实现特定任务。而框架构成了通用的、具有一般性的系统主体部分，“二次开发者”只是像做填空题一样，根据具体业务，完成特定应用系统中与众不同特殊的部分。 框架不是构架（architecture）。构架确定了系统整体结构、层次划分、不同部分之间的协作等设计考虑。框架比构架更具体，更偏重于技术实现。确定框架后，构架也随之确定，而对于同一种构架（比如web开发中的MVC），可以通过多种框架（比如Apache Struts或WebWork）实现。(理解企业应用框架? 选择自 HYPERLINK /user/kxiangli kxiangli 的Blog) 如何最大程度地萃取不同企业应用系统的共性，重复使用已经完成的设计和代码，对企业应用系统中典型场景给出最佳解决方案——这是一个“一般性”的问题；如何让一个早先完成的软件产品贴切地适应极为多变、复杂的企业需求——这是一个“特殊性”的问题。作为对这一组冲突的一种解决方案，不少厂商推出了自己的企业应用框架。这些框架往往是从大量的委托项目开发中精选出的系统“不变项”，因此具有很强的普适性和实用性。 目前，主流企业应用框架中大都包含对以下问题的现成解决方案： 持久性（persistence）