什么是框架
框架（Framework）是整个系统或一部分的可复用设计，是表现为抽象组件和组件实例之间的一组协作关系的交互方法。 该定义从框架内涵的角度定义了框架，当然，也可以从框架用途的角度给出框架的定义。 框架在给定的问题领域内，框架是APP应用的设计和实现的一部分，是APP应用开发者可以定制的APP应用的框架。 前者是从应用方面，后者是从目的方面的定义。
从以上两个定义可以看出，一个框架是可复用的设计组件，是特定应用领域的应用系统的部分设计和实现的整体结构。 定义了APP的体系结构，阐明了设计、协作组件之间的依赖关系、责任分配和整个控制过程，表示为抽象类及其实例之间的一组协作方法，并与组件重用相关联因此，组件库的大规模重用也需要框架。
该框架将APP应用系统划分为类和对象，并定义类和对象的责任、类和对象如何协作以及对象之间的控制线程。 这些共同的设计元素由框架预先定义，APP应用开发者只需要关注特定APP应用系统的特定部分。 由于框架描述了应用领域的通用设计决策，因此可以说框架的重点是设计重用，尽管它可能包含用某种编程语言实现的具体类。
组件框架方法在很大程度上借鉴了硬件技术发展的成果，它是组件技术、软件体系结构研究和应用软件开发三大发展相结合的产物。 框架通常显示为组件库，但组件库只是框架的重要部分。 框架的关键还在于框架中对象之间的交互模式和控制流模式。
框架的定制性比部件高。 从某种意义上说，把部件和框架看作是两种不同但相互合作的技术也许更好。 框架为重用构件提供了环境，并提供了处理错误、交换数据和激活操作的标准方法。
应用框架的概念也很简单。 它不是包含组件APP的小片程序，而是实现了某一应用领域通用的完整功能(特殊APP部分除外)的基础服务。 使用这种框架的程序员可以在共同功能得到落实的基础上开始具体的系统开发。 框架提供了应用期望缺省行为的所有类的集合。 的APP应用程序通过重写子类或程序集对象(框架的缺省行为)来支持APP应用程序特定的行为。
APP应用框架强调了软件的设计复用性和系统的可扩展性，以缩短大型APP应用软件系统的开发周期，提高开发质量。 与传统的基于类库的面向对象重用技术相比，APP应用框架侧重于面向专业领域的软件重用。 应用框架具有域相关性，组件基于框架复合，生成可执行的系统。 框架的粒度越大，其中所包含领域的知识就越完整。
框架，即框架。 其实是某种应用的半成品，一系列的组件，你可以选择来完成自己的系统。 简单来说，就是用别人搭建的舞台，由你来表演。 而且，框架一般是成熟的，不断升级的软件。
基于框架开发的APP应用系统包括一个或多个框架、与框架相关的组件类以及与APP应用系统相关的功能扩展。 与APP应用程序系统相关的扩展包括与APP应用程序系统相关的类和对象。 APP应用可能只重用了面向对象的框架的一部分，也可能需要对框架进行适应性修改以满足系统的需要。
面向对象框架作为一种可复用的软件，基于框架的软件开发涉及框架的开发和利用两方面的工作。 框架的开发阶段是生成域中的可复用设计。 此阶段的主要结果是框架和与框架相关的组件类。 这个阶段的一个重要活动是框架的演变和维护。 和所有软件一样，框架也容易变化。 应用错误、业务领域的变化等，变化的原因有很多。
不管是哪种技术，最终都是为业务的发展服务。 从业务的观点来说。 首先，框架是为企业的业务发展和战略规划服务的，他遵循企业的愿景。其次，框架最重要的目标是提高企业的竞争力，包括降低成本、提高质量、改善客户满意度、控制进度等最后，实现这一目标的框架方式是进行有效的知识积累。 软件开发是一项知识活动，因此知识的集聚和积累至关重要。 框架可以用结构化的方法描述特定的业务领域。 这意味着可以通过代码、文档、模型等方法固化与这一领域相关的技术。
为什么要用框架？
软件系统的发展直到今天都很复杂。 特别是服务器端软件，涉及的知识、内容和问题太多了。 在某些方面使用别人成熟的框架，就像让别人帮你做基础工作一样，你只需要专注于系统的业务逻辑设计。 此外，框架普遍成熟、稳健，能够处理系统的许多细节问题，如事物的处理、安全性和数据流控制。 还有框架一般很多人都在使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，所以可以直接享受别人升级代码带来的好处。
通常，框架位于子APP应用平台(如J2EE )和上层业务逻辑之间的中间层。 软件分层的好处是实现“高凝聚、低耦合”。 把问题分开解决，容易控制，容易扩展，容易分配资源……总之好处很多。
框架和设计模式
框架、设计模式这两个概念很容易混淆，但其实它们之间是有区别的。
通常，组件是代码的复用，设计模式是设计的复用，框架介于两者之间，部分代码被复用，部分设定
计重用，有时分析也可重用。在软件生产中有三种级别的重用：内部重用，即在同一应用中能公共使用的抽象块；代码重用，即将通用模块组合成库或工具集，以便在多个应用和领域都能使用；应用框架的重用，即为专用领域提供通用的或现成的基础结构，以获得最高级别的重用性。
框架与设计模式虽然相似，但却有着根本的不同。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；框架可以用代码表示，也能直接执行或复用，而对模式而言只有实例才能用代码表示;设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应用领域，但同一模式却可适用于各种应用。可以说，框架是软件，而设计模式是软件的知识。
框架开发
框架的最大好处就是重用。面向对象系统获得的最大的复用方式就是框架，一个大的应用系统往往可能由多层互相协作的框架组成。
由于框架能重用代码，因此从一已有构件库中建立应用变得非常容易，因为构件都采用框架统一定义的接口，从而使构件间的通信简单。
框架能重用设计。它提供可重用的抽象算法及高层设计，并能将大系统分解成更小的构件，而且能描述构件间的内部接口。这些标准接口使在已有的构件基础上通过组装建立各种各样的系统成为可能。只要符合接口定义，新的构件就能插入框架中，构件设计者就能重用构架的设计。
框架还能重用分析。所有的人员若按照框架的思想来分析事务，那么就能将它划分为同样的构件，采用相似的解决方法，从而使采用同一框架的分析人员之间能进行沟通。
框架主要优点
1、代码模板化
框架一般都有统一的代码风格，同一分层的不同类代码，都是大同小异的模板化结构，方便使用模板工具统一生成，减少大量重复代码的编写。在学习时通常只要理解某一层有代表性的一个类，就等于了解了同一层的其他大部分类结构和功能，容易上手。团队中不同的人员采用类同的调用风格进行编码，很大程度提高了代码的可读性，方便维护与管理。领域内的软件结构一致性好； 建立更加开放的系统；
2、重用
开发框架一般层次清晰，不同开发人员开发时都会根据具体功能放到相同的位置，加上配合相应的开发文档，代码重用会非常高，重用代码大大增加，想要调用什么功能直接进对应的位置去查找相关函数，而不是每个开发人员各自编写一套相同的方法，大粒度的重用使得平均开发费用降低，开发速度加快，开发人员减少，维护费用降低，而参数化框架使得适应性、灵活性增强，软件生产效率和质量也得到了提高。
3、高内聚（封装）
框架中的功能会实现高内聚，开发人员将各种需要的功能封装在不同的层中，给大家调用，而大家在调用时不需要清楚这些方法里面是如果实现的，只需要关注输出的结果是否是自己想要的就可以了。
4、规范
框架开发时，必须根据严格执行代码开发规范要求，做好命名、注释、架构分层、编码、文档编写等规范要求。因为你开发出来的框架并不一定只有你自己在用，要让别人更加容易理解与掌握，这些内容是非常重要的。
5、可扩展
开发框架时必须要考虑可扩展性，当业务逻辑更加复杂、数量记录量爆增、并发量增大时，能否通过一些小的调整就能适应？还是需要将整个框架推倒重新开发？当然对于中小型项目框架，也不必考虑太多这些内容，当个人能力和经验足够时水到渠成，自然就会注意到很多开发细节。
7、可维护
成熟的框架，对于二次开发或现有功能的维护来说，操作上应该都是非常方便的。比如项目要添加、修改或删除一个字段或相关功能，只需要简单的操作，十来分钟或不用花太多的工夫就可以搞定。新增一个数据表和对应的功能，也可以快速的完成。功能的变动修改，不会对系统产生不利的影响。代码不存在硬编码等等，保证软件开发的生产效率和质量。
8、协作开发
有了开发框架，我们才能组织大大小小的团队更好的进行协作开发，有利于在一个项目内多人协同工作；成熟的框架将大大减轻项目开发的难度，加快开发速度，降低开发费用，减轻维护难度。
9、通用性
同一行业或领域的框架，功能都是大同小异的，不用做太大的改动就可以应用到类似的项目中。在框架中，我们一般都会实现一些同质化的基础功能，比如权限管理、角色管理、菜单管理、日志管理、异常处理......或该行业中所要使用到的通用功能，使框架能应用到某一行业或领域中，而不是只针对某公司某业务而设定（当然也肯定存在那些特定功能的应用框架，这只是非常少的特殊情况，不在我们的考虑范围）。
搭建框架时要如何定位
是不是框架的扩展性、可移值性、功能越强大就越好呢？
好的框架是相对的，它都有自己特定的应用领域，合适才是最好。
个人觉得在实际开发中要根据具体情况来看的，因为功能越全面它的复杂度就越大，所需要的开发人员能力和技能就会要求更高，付出的成本也就最大。比如做一个还未发展起来的电商网就想 将系统做成像京东那样，直接用京东分模块分布式的框架来开发，那得怎么来组建这个团队？更不用说开发成本了。就算团队有能力做到，也没有那个必要这么去做，因为从成本预算和开发周期等方面来看，得不尝失，更多的可能项目还未完成公司就给拖垮了。
一般来说，一个中小型项目，1到5人左右的开发团队，使用一般的三层结构就可以了，不用去细想框架要分三层还是五层，每个层之间要怎么实现解耦，要用什么设计模式.....因为当今飞速发展的互联网时代，快才是王道，做一个中小型项目能用一周完成的，绝不能拖了一个月还未做完。人工与时间成本才是重点中 的重点，唯有快才能更好的生存下来并壮大。至于扩展功能、接口、分布式、并发、大数据......等等问题，实际上过早考虑太多并不是好事情，有经验的程序员在写这个框架时早已留下扩展方案或思路，而没到这一层次的开发人员你想再多也可能想不明白，还不如先做出来积累一定经验后再慢慢学习，慢慢升级框架。
当然也不是说设计框架时不用考虑高内聚低耦合，而是要根据自己的能力与经验来设计出自己能把控的框架出来。因为框架不是开发出来后就不再变动，它也需要不停的进行升级，将你所学到的新知识新技术融合到框架中，使它的功能更加强大，更加健壮。而对于自己不能把控的框架，在团队协作开发和上生产环境后，你就发现有一大堆的坑等着你去填埋，这种框架只能拿来先练练手，有空再慢慢完善。
框架通过小步快跑，不断的迭代升级来慢慢扩展的，当项目上生产环境后，根据新的需求和所碰到的问题，去不停的调整，最终越来越强大。所有框架都是从1.0版本到2.0、3.0......发展而来，而不是直接跳过最初版本到最终成熟版本。
所以说我们在创建一个框架时，必须根据我们当前个人的技术能力、团队成功技术水平、时间、投入成本、项目现状（规模与需求复杂程度）、以后的发展前景来决定所要开发的框架的最终设计方案。当然也不是说不能一步到位，心有多大世界就有多大，只要个人能力和团队能力配得上，老板资金成本雄厚，时间充足，直接上大项目使用超级框架也完全没有问题。