架构_框架_模式_构件_组件_中间件之间区别

1、1. 什么是架构？架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；架构决策往往会体现在框架之中。或许，人们常把架构和框架混为一谈的原因就在于此吧。架构、框架、模式是一种从大到小的关系，在某种程度上讲也是一种组合关系。架构一般针对一个行业或一类应用，是技术和应用完美的结合。框架因为比较小，很多表现为中间件，框架一般是从技术角度解决同类问题，例如J道数据增删改查框架就解决了所有数据库系统中大量数据增删改查的功能开发，框架是从技术的横切面去解决

2、实际应用问题。模式则更小了，越小越灵活，可重用的范围更广。一个框架可能使用了多个模式，而一个架构有可能应用到了多个框架中，这样一个大型系统的设计基本从主骨干到骨架基本能够被设计者考虑设计到，也可以想见，一个系统被细化成了很多工作量，例如一个部分细化到工厂模式，那么就可以要求程序员实现工厂模式的代码即可。由此，控制了大型软件质量，也提高开发效率，同时使得项目变得易于管理和协同，由此可见，一个大型项目的架构设计非常重要。2. 什么是框架？框架，即framework。其实就是系统或子系统的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的

3、，不断升级的软件。3. 什么是模式？模式，即pattern。其实就是解决某一类问题的方法论。你把解决某类问题的方法总结归纳到理论高度，那就是模式。Alexander给出的经典定义是：每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心。通过这种方式，你可以无数次地使用那些已有的解决方案，无需在重复相同的工作。模式有不同的领域，建筑领域有建筑模式，软件设计领域也有设计模式。当一个领域逐渐成熟的时候，自然会出现很多模式。4. 什么是构件？构件（component）是可复用的软件组成成份，可被用来构造其他软件。它可以是被封装的对象类、类树、一些功能模块、软件框架（fra

4、mwork）、软件构架（或体系结构Architectural）、文档、分析件、设计模式（Pattern）等。构件分为构件类和构件实例，通过给出构件类的参数，生成实例，通过实例的组装和控制来构造相应的应用软件，这不仅大大提高了软件开发者的开发效率，也大大提高了软件的质量。构件的物理形式表现为制品。5. 什么是控件？一、组件概念简而言之，组件就是对象。C+ Builder中叫组件，Delphi中叫部件，而在Visual BASIC中叫控件。组件是对数据和方法的简单封装。C+ Builder中，一个组件就是一个从TComponent派生出来的特定对象。组件可以有自己的属性和方法。属性是组件数据的简单

5、访问者。方法则是组件的一些简单而可见的功能。组件是C+ Builder环境中最令人激动的部分。使用组件可以实现拖放式编程、快速的属性处理以及真正的面向对象的设计。VCL和CLX组件是C+ Builder系统的核心。二、组件应用使用现成的组件来开发应用程序时，组件工作在两种模式下：设计时态和运行时态。在设计时态下，组件显示在C+ Builder窗体编辑器下的一个窗体中。设计时态下组件的方法不能被调用，组件不能与最终用户直接进行交互操作，也不需要实现组件的全部功能。在运行状态下，组件工作在一个确实已经运行的应用程序中。组件必须正确地将自身表示出来，它需要对方法的调用进行处理并实现与其他组件之间有效

6、的协同工作。设计时态下所有的组件在窗体中都是可见的，但在运行时态下不一定可见。如TTable、TQuery和TDataSet在运行时态下就不可见，但他们均完成了重要的功能。三、组件创建创建组件就是自行设计制作出新的组件。设计组件是一项繁重的工作。自行开发组件与使用组件进行可视化程序开发存在着极大的不同，要求程序员熟知原有的VCL类库结构，精通面向对象程序设计。设计组件是一项艰苦的工作。对于组件的开发者，组件是纯粹的代码。组件的开发不是一个可视化的开发过程，而是用C+或Object Pascal严格编制代码的工作。实际上，创建新组件使我们回到传统开发工具的时代。虽然这是一个复杂的过程，但也是一个

7、一劳永逸的过程。创建组件的最大意义在于封装重复的工作，其次是可以扩充现有组件的功能。组件创建过程包括设计、开发、调试（就是所谓的3D's）工作，然后是组件的使用。组件开发者应该掌握的三项主要内容是：属性、事件和方法。6. 什么是中间件？中间件作为一大类系统软件,与操作系统,数据库管理系统并称"三套车",其重要性是不言而语的. 我们来看看以下的几种定义:Middleware, is a layer of software between the network and the applications. This software provides services

8、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 adva

9、nced network applications much easier to use.同样,IDC给出的一个定义：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。从这些定义中可以看出:l 中间件是一类软件，而非一种软件；l 中间件不仅仅实现互连，还要实现应用之间的互操作；l 中间件是基于分布式处理的软件，最突出的特点是其网络通信功能。7. 什么是平台框架（Framework）和平台（Platform）是软件行业中经常看到的术语，应当说也是这个行业发展的方向。在讨论其重要性之前，我们先看看

10、两者在概念上的区别。       框架是针对一定的应用领域进行开发的，比如，ACE（Adaptive Communication Environment）就是针对网络通讯而开发的一个框架。框架通常对于应用进行了一定的抽象，将需要的一些通用的功能做成了软件模块。当用户（或开发人员）需要对应用进行开发时（即实现应用的功能时），如果采用框架，则只要实现针对应用的特定代码就行了。或者，我们可以理为：解框架为相类似的应用设计了一个骨架，而具体的应用只是在这个骨架上填上肉和皮肤。假如要做一个Server/Client程序，如果采用ACE，我们可以在Server侧用

11、Acceptor来监听连接请求，而在Client侧则用Connector来发起连接。最后，Server与Client之间是一定有协议的，这些协议是针对特点的应用的，并不是框架的一部分，是用户必须其于框架去实现的特定的代码。    平台是通常和一定的操作系统相关，是对操作系统更高层次的抽象。平台一方面提供了所有使用硬件资源的API，另一方面也实现了一些通用的组件，这些组件可以服务于不同的应用领域。比如，常用的平台模块有，内存管理模块、Log管理模块、设备管理模块，等等。    如果用分层的概念来看框架和平台，假设上面是应用层，下面是硬件层，那么，我们可以认

12、为框架是在平台之上的，是更加接近应用的。而平台是在框架之下的，是更加的通用的。同一个平台可以为不同的框架（应用领域）服务的。    框架和平台是目前行业很重要的开发方向，这足以体现了其重要性，那为什么会如此重要呢？我想总的来说应当是：为了代码重用和开发出高质量的软件。无论是框架还是平台，其思想都是为了代码重用。代码重用的好处，一是缩短开发时间，二是可以少犯相同的错误，而这也就提高了软件质量。此外，两者都是更高抽象层次的软件开发方法，是避免“重新造轮子”的开发方法。    通常一个好的框架设计都会基于一定的平台的，当然，平台可以有简单和复杂，框架中所使用的

13、平台是应当是简单还是复杂，其标准应当是：保证框架能很快的被移植到新的操作系统。可见，有平台概念的框架有更强的适应性和生命力。应当说JAVA的兴起，给框架的发展打开了全新的篇章。    平台的设计除了对于现有的操作系统进行更高抽象层次的封装外，我认为基于虚拟机的语言的开发是一种新形式的平台开发。比如，Python、Java，其本身是构建在虚拟机上的，而其丰富的库可以说构建了平台的功能。这种形式的好处是，跨平台成了开发虚拟机的工作，而这通常都是由语言的创造者（社区或是公司）去完成的。8. 温昱谈架构和框架的区别软件架构存在非常多的误解，其中最为普遍的就是：将架构（Archite

14、cture）和框架（Framework）混为一谈。简言之，框架是软件，架构不是软件。一图胜千言，下图切中肯綮地点出了架构和框架的区别。图表 81框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。典型地，框架是系统或子系统的半成品；框架中的服务可以被最终应用直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”。架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，引入软件框架之后

15、，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中。或许，人们常把架构和框架混为一谈的原因就在于此吧。理解了本图，我们就很容易理解Frank Buschmann等人在面向模式的软件体系结构（第一卷）中为框架所下的定义了，其中也提到了框架和架构的关系：框架是一个可实例化的、部分完成的软件系统或子系统，它为一组系统或子系统定义了架构，并提供了构造系统的基本构造块，还为实现特定功能定义了可调整点。在面向对象环境中，框架由抽象类和具体类组成。（A framework is a partially complete software (sub-) system that is intended to be instantiated. It defines the architecture for a family of (sub-)