框架、模式、架构、构件、组件、中间件概要

简单来说：

框架(Framework) 解决某一方面应用问题的半成品软件
模式（Pattern） 为解决某一类问题而提出的一种解决方案，是方法论。
架构(Architecture) 整体解决方案
构件（Component） 可复用的软件组成成份
组件 对象（封装数据和方法）
中间件 基于分布式处理的一类软件（位于网络和应用程序之间）

一、框架（Framework）

框架，即Framework。其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。而架构并不是代码，是一种解决方案，是解决问题的综合体。

像struts、spring、hibernate这些非常著名的开源框架，它们都是针对某一方面的应用而提出解决问题的半成品软件。比如说struts 专门用于解决前端开发，是MVC实现的一种很好的解决方式。spring解决的范围就广了，它的web组件同样用于解决前端开发，而ioc容器则用于解决 对象之间的解耦与分离，AOP则更是将对象方法之间的协作问题提升到神不知鬼不觉的情况下解决掉（牛啊），当然，spring还有持久化，缓存，事务等方 面的专门解决组件，是通过对其它著名框架的集成而得到的。这样我们会发现，当我们想解决某一类问题时，我们不用从零开始编写代码，框架已经为我们封装好了 一套解决方法，提供了API给我们使用。总之，框架并不是现成可用的应用系统。它只是一个半成品，需要后来的开发人员进行二次开发，实现具体功能的应用系 统。

那么，这些框架为何如此优秀，是如何被设计出来呢？它们的优秀，在于一方面很好地解决了某一领域的问题（或多个领域），让我们不再从零开始造轮子；另一方 面也在于它们相对于其它同样解决此问题的方法中，具有较好的性能。我想一个封装得再好的框架，如果性能低劣差劲，是不会被人追棒的。真正封装得好的框架， 让我们不必去关心这个框架究竟是怎么产生的，只需调用api就能完成我们的开发，这才是方便的框架。要设计出这样的框架，我们就要有想法，有思路，有设 计。而我们通过某种方法或某种思想来解决某种问题，这便是设计模式了。


二、设计模式（Design Pattern）
　　
模式是一种解决问题的思路，而不是具体的做法。在软件开发领域，设计模式是为解决某一类问题而提出的一种解决方案，是方法论。因此，设计模式本质上是思 想，而不是代码。你把解决某类问题的方法总结归纳到理论高度，那就是模式。而代码，仅仅是用来表达你的思想，将很抽象的思想上的东西用代码活生生的形象的 表达出来而已。

由于设计模式关注的“点”是如此之小，所以实际开发中，你几乎不会遇到用了某某设计模式就可以解决一个业务问题的情况。而且设计模式，主要的目标不是解决业务问题，而是改善代码的结构，从而整体上提高应用程序的结构质量。

许多开发者有一种误解，那就是“应用设计模式的目的是代码复用”。其实，设计模式追求的复用，是思想上的复用。也就是你解决某一类型问题时的解决方案，可以在下一次遇到同类问题时重复使用。

　　模式有不同的领域，建筑领域有建筑模式，软件设计领域也有设计模式。当一个领域逐渐成熟的时候，自然会出现很多模式。

而模式与框架，它们是软件设计上的两个不同的研究领域。但是，为了得到一个优秀的框架，我们总要想方设法去进行抽象进行设计，以期达到可复用、易维护、低耦合等目标，因此我们需要利用适当的模式来进行设计，再用代码给予实现。

当然，设计模式的作用并不是仅仅用来设计框架，那样理解就过于片面。设计模式是给出了某一个单一设计问题的解决方案，并且这个方案可在不同的应用程序或者 框架中进行应用。设计模式仅仅是一个单纯的设计，这个设计可被不同语言以不用方式来实现，可以在不同应用中复用；而框架则是模式和代码的一个混合体，编程 者可以用各种方式对框架进行扩展，进而形成完整的不同的应用。

可是我们的开发并非是以模式和框架为指导的，我们在不同的应用开发中，需要遵循不同的规约，这些规约包括了整体结构、层次划分、不同部分之间的协作、功能 边界、系统性能处理、适当的技术选型、框架使用、模式应用、是否分布式、代码规范等等因素。而这些因素中的任何一个，都是非常重要的，这些因素综合起来构 成了我们的开发规约。而针对这些因素的综合考虑，提出解决开发应用中问题的方案，便是架构。


三、架构(Architecture)

架构 —— 这个词的适用范围是可变的。

对于 google 整个公司的信息系统，有一个架构。具体到某一个应用，例如 google docs，又是一个架构。再缩小范围到一个应用程序，还是有一个架构。
所以，架构到底指什么，必须考虑这个词所处的上下文。

设计模式关注一个很小的“点”。架构则关注一个“面”。
架构，试图从整体结构上为解决某一组问题提供一个方案。
架构一般针对一个行业或一类应用，是技术和应用完美的结合。

学术性点的表达就是，架构包括了一系列的部件、部件之间的关系、部件接口，它体现了对基础原理的决策。架构是对软件系统的系统组织，是对构成系统的构件的 接口，行为模式，协作关系等体系问题的决策总和。它不仅涉及到结构与行为，而且还涉及到系统的使用、功能、性能、适应性、重用性、可理解性、经济性和技术 约束的权衡和美学考虑。一般而言，软件系统的架构有两个要素：

·它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。详细地说，就是要包括架构元件 （Architecture Component）、联结器（Connector）、任务流（Task-Flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些 元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。


四、框架、模式、架构总结

一个框架可能使用了多个模式，而一个架构有可能应用了多个框架。

框架的创造者根据自己的知识和经验，为解决某一个领域的基础问题，提出了自己的设计思想。然后根据这个设计思想创造出了框架。在这个框架中，必然会运用许多设计模式来保持框架整体结构的质量。

所以设计模式和框架的关系很简单：设计模式是实现框架时用到的“工具”！

而架构和框架的关系就很复杂了。

对于一个简单的应用程序，整个架构就是框架的架构。

而对于复杂的应用程序，一个框架只是整体架构中的一部分。
例如表现层采用 PHP 和 xxxxphp 框架，而业务层采用 Java 和 xxxjava 框架。


五、使用框架和模式的意义

1. 为什么要用框架
　 　因为软件系统发展到今天已经很复杂了，特别是服务器端软件，设计到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些 基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统很多细节问题，比如，事物处理，安全性，数据流控制等问 题。还有框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。
框架一般处在低层应用平台(如J2EE)和高层业务逻辑之间的中间层。

2．为什么要用模式
　　因为模式是一种指导，在一个良好的指导下，有助于你完成任务，有助于你作出一个优良的设计方案，达到事半功倍的效果。而且会得到解决问题的最佳办法。


六、构件（Component）

构件（component）是可复用的软件组成成份，可被用来构造其他软件。它可以是被封装的对象类、类树、一些功能模块、软件框架 （Framwork）、软件构架（或体系结构Architectural）、文档、分析件、设计模式（Pattern）等。构件分为构件类和构件实例，通 过给出构件类的参数，生成实例，通过实例的组装和控制来构造相应的应用软件，这不仅大大提高了软件开发者的开发效率，也大大提高了软件的质量。


七、组件

1. 组件概念
简而言之，组件就是对象。C++ Builder中叫组件，Delphi中叫部件，而在Visual BASIC中叫控件。
组件是对数据和方法的简单封装。C++ Builder中，一个组件就是一个从TComponent派生出来的特定对象。组件可以有自己的属性和方法。属性是组件数据的简单访问者。方法则是组件的一些简单而可见的功能。
组件是C++ Builder环境中最令人激动的部分。使用组件可以实现拖放式编程、快速的属性处理以及真正的面向对象的设计。VCL和CLX组件是C++ Builder系统的核心。

2. 组件应用
使用现成的组件来开发应用程序时，组件工作在两种模式下：设计时态和运行时态。
在设计时态下，组件显示在C++ Builder窗体编辑器下的一个窗体中。设计时态下组件的方法不能被调用，组件不能与最终用户直接进行交互操作，也不需要实现组件的全部功能。
在运行状态下，组件工作在一个确实已经运行的应用程序中。组件必须正确地将自身表示出来，它需要对方法的调用进行处理并实现与其他组件之间有效的协同工作。
设计时态下所有的组件在窗体中都是可见的，但在运行时态下不一定可见。如TTable、TQuery和TDataSet在运行时态下就不可见，但他们均完成了重要的功能。

3. 组件创建
创建组件就是自行设计制作出新的组件。
设计组件是一项繁重的工作。自行开发组件与使用组件进行可视化程序开发存在着极大的不同，要求程序员熟知原有的VCL类库结构，精通面向对象程序设计。
设计组件是一项艰苦的工作。对于组件的开发者，组件是纯粹的代码。组件的开发不是一个可视化的开发过程，而是用C++或Object Pascal严格编制代码的工作。实际上，创建新组件使我们回到传统开发工具的时代。虽然这是一个复杂的过程，但也是一个一劳永逸的过程。
创建组件的最大意义在于封装重复的工作，其次是可以扩充现有组件的功能。
组件创建过程包括设计、开发、调试（就是所谓的3D's）工作，然后是组件的使用。
组件开发者应该掌握的三项主要内容是：属性、事件和方法。

八、中间件

中间件作为一大类系统软件，与操作系统，数据库管理系统并称“三套车”，其重要性是不言而语的。

我们来看看以下的几种定义:

Middleware, is a layer of software between the network and the applications. This software provides services such as identification, authentication, authorization, directories, and security. In today's Internet, applications usually have to provide these services themselves, which leads to competing and incompatible standards. By promoting standardization and interoperability, middleware will make advanced network applications much easier to use.

同样,IDC给出的一个定义：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。

从这些定义中可以看出：
中间件是一类软件，而非一种软件；
中间件不仅仅实现互连，还要实现应用之间的互操作；
中间件是基于分布式处理的软件，最突出的特点是其网络通信功能。