架构风格

传统的架构风格

依据David Calvert在1996年给出了一份架构风格/模式的清单,架构风格包括了:

  • 数据流系统——批处理,管道-过滤器。
  • 调用-返回系统——主程序和子程序,面向对象系统,分层。
  • 独立组件——通信过程,事件系统。
  • 虚拟机——解释器,基于规则的系统。
  • 以数据为中心的系统(仓库)——数据库,超文本系统,黑板。

数据流风格

面向数据的架构风格,软件的处理粒度是赤裸裸的“数据”,而不需对数据进行任何的“包装”。

批处理序列

组件为一系列固定顺序的计算单元(独立程序),组件间只通过数据传递交互。数据计算单元的执行必须在前一单元完全结束后才能开始,数据以整体的方式传递。

管道/过滤器

每个构件都有一组输入和输出,构件读取输入的数据流,经过内部处理,然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成,包括通过计算和增加信息丰富数据,通过浓缩和删除精炼数据,通过改变记录方式转化数据,递增地转化数据等。在输入被完全消费之前,输出便产生了。这里构件被称为过滤器,连接件就是数据流传输的管道,将一个过滤器的输出传到另一个过滤器的输入。

此风格要求过滤器必须是独立的实体,它不能与其它的过滤器共享数据,而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。

总结

优势:

  • 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点;
  • 构件之间的组合、重用十分简单,易于拼接成业务功能块;

限制:

  • 不适合处理交互的应用。由于业务功能块是按照结构化的流程设计的,所以只适用于处理特定的逻辑流程。当需要增量地显示改变时,这个问题尤为严重。
  • 数据由于没有任何封装,传输上没有通用的标准,每个过滤器都增加了解析和合成数据的工作,这样就导致了系统性能下降,并增加了编写过滤器的复杂性。

调用/返回风格

主程序 & 子程序

采用单线程控制,把问题划分为若干处理步骤,构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制,即充当连接件。调用关系具有层次性,其语义逻辑表现为子程序的正确性,取决于它调用的子程序的正确性。

面向对象

这种风格的构件是对象。对象是抽象数据类型的实例。在抽象数据类型中,数据的表示和它们的相应操作被封装起来。对象的行为体现在其接受和请求的动作。连接件即对象间交互的方式,对象是通过函数和过程的调用来交互的。这种结构风格中包含有封装、交互、多态、集成和重用等特征。

层次结构

层次系统组织成一个层次结构。连接件通过决定层间如何交互的协议来定义,拓扑约束包括对相邻导间交互的约束。这个风格将大的问题分解为若干个渐进的小问题,逐步解决,隐藏了很多复杂度。修改一层,最多影响两层,而通常只能影响上层。上层必须知道下层的身份,不能调整层次之间的顺序。

优点:

  • 支持基于抽象程度递增的系统设计,使设计者可以把一个复杂系统按递增的步骤进行分解;
  • 支持重用。只要提供的服务接口定义不变,同一层的不同实现可以交换使用。

独立构件风格

进程间通信

构件是独立的过程,连接件是消息传递。这种风格的特点是构件通常是命名过程(进程),消息传递的方式可以是点到点、异步和同步方式及远过程调用(RPC)等。在这种架构中,消息的传递目标是显式声明的——明确指向另外一个构件。

事件驱动架构

构件不直接调用一个过程,而是触发或广播一个或多个事件。系统中其他构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的处理机制。一个事件的触发就导致了另一个模块中过程的调用——这本身属于一种异步机制的实现(实际上有些事件的响应是以同步方式实现的)。

从体系结构上说,这种风格的构件是一些模块,这些模块既可以是一些过程,又可以是一些事件的集合。过程可以用通用的方式调用,也可以在系统事件中注册一些过程,当发生这些事件时,过程被调用。

构件之间交互的连接件往往是以过程之间的隐式调用(Implicit Invocation)来实现的。基于事件的隐式调用风格的主要优点是为软件重用提供了强大的支持,为构件的维护和演化带来了方便;其缺点是构件放弃了对系统计算的控制。

优点:

  • 为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时,只需将它注册到系统的事件中,十分灵活。

缺点:

  • 构件放弃了对系统计算的控制。一个构件触发一个事件时,不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成,它也不能保证这些过程被调用的顺序;
  • 既然过程的语义必须依赖于被触发事件的上下文约束。

虚拟机

解释器

一个解释器通常包括完成解释工作的解释引擎,一个包含将被解释的代码的存储区,一个记录解释引擎当前工作状态的数据结构,以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机,可以仿真硬件的执行过程和一些关键应用;其缺点是执行效率较低。

基于规则的系统

基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。

仓库风格

在仓库风格中,有两种不同的构件:中央数据结构(仓库)说明当前状态,独立构件在中央数据存贮上执行。

数据库架构(共享数据)

数据库架构是仓库风格最常见的形式。构件主要有两大类,一个是中央共享数据源,保存当前系统的数据状态;另一个是多个独立处理元素,处理元素对数据元素进行操作。例如二层C/S架构中不同的服务项对服务数据库的访问模型。

黑板架构

黑板架构包括知识源、黑板和控制3个部分。

  • 知识源包括若干独立计算的不同单元,提供解决问题的(与应用程序相关的)知识,知识源响应黑板上的变化,也只修改黑板  ==> 独立算法模块;
  • 黑板是一个全局数据库,包含问题域解空间的全部状态。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据,知识源通过不断地改变黑板数据来解决问题。
  • 控制逻辑:控制完全由黑板的状态驱动,黑板状态的改变决定使用的特定知识。

黑板通常应用在对于解决问题没有确定性算法的系统中,例如信号处理、问题规划及编译器优化等软件系统的设计中。

超文本系统

构件以网状连接方式相互连接,用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法,它以结点为基本单位,链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。

原文地址:https://www.cnblogs.com/brt3/p/9859933.html

时间: 2024-10-11 17:57:59

架构风格的相关文章

理解本真的REST架构风格

引子 在移动互联网.云计算迅猛发展的今天,作为一名Web开发者,如果您还没听说过“REST”这个buzzword,显然已经落伍了.夸张点说,甚至“出了门都不好意思跟别人打招呼”.尽管如此,对于REST这个泊来品的理解,大多数人(包括一些资深的架构师)仍然停留在“盲人摸象”的阶段.常常听到各种各样关于REST的说法,例如:有人说:“我们这套新的API决定不用Web Service(SOAP+WSDL),而是直接使用HTTP+JSON,也就是用RESTful的方式来开发.” 不用SOAP,甚至也不用

搭建基于spring MVC框架 + RESTful架构风格技术总结

实战篇: 在SpringMVC框架中搭建RESTful架构风格来完成客户端与服务器端的低耦合度.可扩展性.高并发与大数据流量的访问. 用RESTful架构的创建步骤: 1.创建一个全新的Web工程 2.导包,导入所需要的所有第三方jar包.(springMVC+Hibernate的基本包是必须的) 3.作配置,针对不同的项目需求和不同的搭建设计,开发人员可以按照自己的编码风格来设计符合项目开发具体 应该用多少篇配置文件.但是这几篇配置文件是必不可少的: 3-1.web.xml配置文件:最基本的配

中文翻译为"具象状态传输"的RESTful的架构风格和设计思想

本文标签:  具象状态传输 RESTful架构 RESTful理解 REST   服务器 REST 定义了一组体系架构原则,您可以根据这些,包括使用不同语言编写的客户端如何通过 HTTP 处理和传输资源状态.所以在事实上,REST 对 Web的影响非常大,由于其使用相当方便,已经普遍地取代了基于 SOAP 和 WSDL 的接口设计.在多年以后的今天,REST的主要框架已经开始雨后春笋般的出现. REST(Representational State Transfer ),有中文翻译为"具象状态传

理解本真的REST架构风格(转)

本文是“深入探索REST”专栏系列深度内容中的第二篇,它将带您领略REST架构的起源.与Web的关系.REST架构的本质及特性,以及REST架构与其他架构风格之间的比较. 引子 在移动互联网.云计算迅猛发展的今天,作为一名Web开发者,如果您还没听说过“REST”这个buzzword,显然已经落伍了.夸张点说,甚至“出了门都不好意思跟别人打招呼”.尽管如此,对于REST这个泊来品的理解,大多数人(包括一些资深的架构师)仍然停留在“盲人摸象”的阶段.常常听到各种各样关于REST的说法,例如:有人说

架构风格之比较

转至InfoQ上的<理解本真的REST架构风格>一文 从架构风格的抽象高度来看,常见的分布式应用架构风格有三种: 分布式对象(Distributed Objects,简称DO) 架构实例有CORBA/RMI/EJB/DCOM/.NET Remoting等等 远程过程调用(Remote Procedure Call,简称RPC) 架构实例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等 表述性状态转移(Representational State Transfer,简称

关于“考勤助手”体系架构风格的选取

“考勤助手”体系架构风格的选取 备选其一:分层系统,由于考勤助手这款软件需要用到用户图像层面的设计,将用户需求与数据库对接的功能接口层设计以及数据库本身提供数据的层面设计.我们认为分层系统对于这款软件的架构是较为合适的,不仅是因为该软件的每一层都需要为上一层服务,更是因为分层系统本身具有着很好的优点: 1.这种风格支持基于可增加抽象层的设计,允许我们讲一个复杂问题分解成一个增量步骤序列的实现. 2.因为每一层的修改最多影响其上下两层的连接,所以我们在每一层抽象的基础上可以提供更加合理的邻层接口,

【DDD】领域驱动设计实践 —— 架构风格及架构实例

概述 DDD为复杂软件的设计提供了指导思想,其将易发生变化的业务核心域放置在限定上下文中,在确保核心域一致性和内聚性的基础上,DDD可以被多种语言和多种技术框架实现,具体的框架实现需要根据实际的业务场景和需求来制定. 核心的指导思路归纳为: 关注点放在domain上,将业务领域限定在同一上下文中 降低上下文之间的依赖,通过‘开发主机服务’(REST服务是其中的一种).‘消息模式’.‘事件驱动’等架构风格实现 遵循分层架构模式 架构风格 针对DDD的架构设计,<实现领域驱动设计>提到了几种架构风

[转]理解本真的REST架构风格-By李锟

最近看到一个词语“REST”风格,就百度了一下,度娘很给力,下面就是我认为写的最好的一篇介绍. 原文地址:http://www.infoq.com/cn/articles/understanding-restful-style 本文是“深入探索REST”专栏系列深度内容中的第二篇,它将带您领略REST架构的起源.与Web的关系.REST架构的本质及特性,以及REST架构与其他架构风格之间的比较. 引子 在移动互联网.云计算迅猛发展的今天,作为一名Web开发者,如果您还没听说过“REST”这个bu

常见架构风格

软件架构决策派定义中列举了一系列架构设计阶段需要完成的决策,其中包括“确定架构风格”,那么什么是架构风格?都有哪些常见的架构风格呢? 定义 架构风格定义了一组可以使用的元素类型(比如模块.组件.连接器等),还定义了一组如何使用这些类型的约束,比如系统的实时拓扑结构.模块之间的依赖及组件之间的可视性等. 其实架构风格就和设计模式类似,都是定义了组件及组件之间的关系,不过抽象层次不同而已,因此他们的作用也很类似. 作用 一致性和可理解性:遵循同一个风格得到的结果是一个好主意被彻底的贯彻实施了,而不是

基于Java的REST架构风格及接口安全性设计的讨论

1.REST即表现层状态传递(Representational [,r?pr?z?n'te?nl] State Transfer,简称REST). (1)REST名词解释: 通俗来讲就是资源在网络中以某种表现形式进行状态转移.分解开来: Resource:所指的不只是数据,而是数据和表现形式的组合: Representational:某种表现形式,比如用JSON,XML,JPEG等: State Transfer:状态变化.通过HTTP动词实现. (2)RESTful API: REST(表述性