开发框架的选择和设计经验谈_PHP
框架，即Framework。其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。
可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文（Context）关系。因此构件库的大规模重用也需要框架。
框架的概念最早起源于Smalltalk环境，其中最著名的框架是Smalltalk 80的用户界面框架MVC（Model-View-Controller）。
框架目前还没有统一的定义，其中Ralph Johnson所给出的定义基本上为大多数研究人员所接受：
一个框架是一个可复用设计，它是由一组抽象类及其实例间协作关系来表达的 【Johnson 98】。
这个定义是从框架内涵的角度来定义框架的，当然也可以从框架用途的角度来给出框架的定义：
一个框架是在一个给定的问题领域内，一个应用程序的一部分设计与实现【Bosch 97】。
框架要解决的问题
框架要解决的最重要的一个问题是技术整合的问题，在J2EE的框架中，有着各种各样的技术，不同的软件企业需要从J2EE中选择不同的技术，这就使得软件企业最终的应用依赖于这些技术，技术自身的复杂性和技术的风险性将会直接对应用造成冲击。而应用是软件企业的核心，是竞争力的关键所在，因此应该将应用自身的设计和具体的实现技术解耦。这样，软件企业的研发将集中在应用的设计上，而不是具体的技术实现，技术实现是应用的底层支撑，它不应该直接对应用产生影响。
为什么要进行框架开发
框架的最大好处就是重用。框架之所以称为框架，是因为它可以重用。在软件组织中形成以框架为核心的开发方式，在开发中使用框架，并在开发完成后改进框架。在这个反覆的过程中，重用的工作就已经开展起来了。面向对象系统获得的最大的复用方式就是框架，一个大的应用系统往往可能由多层互相协作的框架组成。框架能重用设计。它提供可重用的抽象算法及高层设计，并能将大系统分解成更小的构件，而且能描述构件间的内部接口。这些标准接口使在已有的构件基础上通过组装建立各种各样的系统成为可能。只要符合接口定义，新的构件就能插入框架中，构件设计者就能重用构架; 框架还能重用分析。所有的人员若按照框架的思想来分析事务，那么就能将它划分为同样的构件，采用相似的解决方法，从而使采用同一框架的分析人员之间能进行沟通。
框架的再一个好处就是可以优化架构。软件架构，亦即体系结构，包括组件元素、元素互助合作模式、基础要求与限制。这说明架构的设计就是将各组件元素以某些理想的合作模式组织起来，以达成系统的基本功能和限制。框架其实就是在特定领域基于体系结构的可重用的设计，即框架是体系结构在特定领域下的应用。框架代表了一种优秀的软件架构。框架定义了扩展方式，从而规范了框架的使用行为。这使得软件能够保持整体架构的稳定性和一致性。
采用框架技术进行软件开发的主要特点包括：领域内的软件结构一致性好;建立更加开放的系统;重用代码大大增加，软件生产效率和质量也得到了提高;软件设计人员要专注于对领域的了解，使需求分析更充分;存储了经验，可以让那些经验丰富的人员去设计框架和领域构件，而不必限于低层编程;允许采用快速原型技术;有利于在一个项目内多人协同工作;大粒度的重用使得平均开发费用降低，开发速度加快，开发人员减少，维护费用降低，而参数化框架使得适应性、灵活性增强。
框架对组织的作用
知识积累。框架的核心价值是对知识的积累。软件开发是一项知识性的活动。但是知识存在于人的大脑中，是最难进行积累的。而在软件开发中，代码是最确定的知识，人和机器通过浏览代码都能够了解代码所表达的意思，而且不会出现不同的理解。所以，从代码出发进行知识的积累是最佳的办法。框架就是这种思路的产出物。框架包含了大量的代码，这些代码是对某个特定问题领域中抽象概念及这些抽象概念之间关系的描述。所以，框架能够胜任知识积累的工作。
保护资产。知识积累本身就是一项对资产的保护工作。而另一项很重要的保护工作就是软件组织（尤其是企业）需要保证对知识的学习和改进是经过合法授权的。例如，知识的非法外流是任何组织都不希望看到的。将知识积累为框架的形式有助于缓解这种情况。
开发框架的选择和设计
理解了上述开发框架的作用和需要解决的问题后，设计和选择框架的准则就很显而易见了，关于技术上应该考虑的准则我这里就不再赘述，只提出一下个人感觉应该考虑的几个问题：
1：框架应该能够对我们的开发过程提供更多、更好帮助。因为使用框架的原始出发点就是为了通过知识的重用提高开发效率。我们应该知道任何开发框架都不可能是十全十美的，也不可能是适应所有的应用场景的，也就是说任何开发框架都有它适用的范围。因此我们绝不能为了技术而技术，适用就好了，很难简单的说那种技术或框架更好，没有必要陷入技术的反复比较和反复选择的深渊中。
2：学习曲线要平滑，技术是为应用服务的，开发框架的学习一定要简单，上手一定要快，对开发人员的要求不能太高。没有什么比使用能得到更深的体会。需要半个月或者一个月学习周期的框架，可能在还没学会时项目就该结束了。
3： 一定要能得到很好的技术支持。在应用的过程中，或多或少都会出现这样或者那样的问题，如果不能很快很好的解决，会对整个项目开发带来影响。一定要考虑综合成本，其实这是目前应用开源软件最大的问题，碰到问题除了死肯文档就是查阅源代码，或者是网上搜寻解决的办法，通常一个问题就会导致一两天的开发停顿，严重的甚至需要一个星期或者更长，项目的进度就很难控制了。
4：考虑对团队要求的影响，使得组织的开发团队易于组建和在不同开发组之间流动，以使那些优先需要解决的任务能够解决。
5：绝对不能因为个人对技术的好恶和对新技术的追求，而随意使用到框架的设计和开发中。开发框架绝不是简单的技术堆叠和拼奏，应该在团队的共同选择的基础之上建立。