精华内容
下载资源
问答
  • title: MVC、MVP、MVVM架构模式多层架构 date: 2019-07-21 22:52:35 tags: MVC MVP MVVM 三层架构(3-tier application) 多层架构(n-tier application) 一、架构模式 1.1 概要: MVC、MVP、MVVM是目前较为主流的...

    MVC、MVP、MVVM架构模式与多层架构

    个人博客地址:http://radarsoftware.cn/
    date: 2019-07-21 22:52:35
    tags:

    • MVC
    • MVP
    • MVVM
    • 三层架构(3-tier application)
    • 多层架构(n-tier application)

    一、架构模式

    1.1 概要:

    MVC、MVP、MVVM是目前较为主流的三种架构模式,使用架构模式的目的是为了解决界面呈现和逻辑代码分离问题,其中MVP和MVVM都是在MVC的基础上发展而来的,引发发展的主要原因在于各个模块间的耦合度、模块测试引发的问题。

    1.2 MVC :

    MVC(全名:Model View Controller),正如名字一样MVC是使用Model、View、Controller三个模块设计创建 Web 应用程序的模式。
    三个模块介绍及功能:
    模型(Model):提供可视化元素的呈现、处理部分逻辑,包含数据和行为,可以认为是领域模型(domain)或JavaBean组件。通俗的讲就是用于网络请求、数据库、业务逻辑处理等操作并对应应用状态和业务功能的封装以及提供View模块显示的数据。如果对java熟悉的话Model模块最直观的部分就是JavaBean中的实体类和DAO类方法了。
    视图(View):数据的展示、提供用户数据显示及操作的可视化界面。(比如jsp页面)
    控制器(Controller):接受用户的输入指令并调用模型模块和视图模块去完成用户的需求。可以将控制器理解为模型模块和视图模块之间的桥梁,通过控制器管理两个模块的交互,是设计这类构架模式的基础分层目的的模块,一定程度上降低了耦合度、提高了代码重复利用率。
    MVC架构模式

    1.3 MVP :

    MVP(全名:Model-view-presenter),是MVC演变而来的一种软件设计模式。与MVC有一定的相似性:Presenter负责逻辑的处理,Model提供数据,View负责显示。但MVP与MVC有着一个重大的区别:在MVP中View并不直接使用Model,它们之间的通信是通过Presenter(MVC中的Controller)来进行的,所有的交互都发生在Presenter内部, 从理论上去除了View和Model的耦合。
    模块介绍及功能:
    Model:负责存储、检索、操纵数据,但与MVC的Model不同的是MVP的Model与可视化元素的呈现无关,与UI(view)处理逻辑也无关。
    View:数据的展示、提供用户数据显示及操作的可视化界面,同时含有一个Presenter成员变量及逻辑接口
    Presenter:处理与用户交互的负责逻辑。相比于MVC的controller,除了相同的事件触发控制功能,由于去除了View和Model的交互,所有的交互功能都发生在了Presenter(从Model传递需要呈现的可视化元素、View逻辑执行后发送响应等等)。由于解除了View与Model的耦合性,开发者可模拟测试View和Model中的任意一个模块,但明显的是Presenter接口与实现类的增加导致代码冗余度、复杂度会有明显增加。
    MVP架构模式

    1.4MVVM :

    MVVM(全名:Model View ViewModel)MVVM是MVP的进一步发展与规范,实现了View和Model的自动同步。MVVM模式中,一个ViewModel和一个View匹配绑定,所有View中的修改变化,都会自动更新到ViewModel中,同时ViewModel的任何变化也会自动同步到View上显示(ViewModel中的属性都实现了observable这样的接口,当使用属性 的set的方法,都会同时触发属性修改的事件,使绑定的View自动刷新,一般由不同的前端框架平台封装例如VUE。),ViewModel和View之间的交互通过Data Binding完成, 而Data Binding可以实现双向的交互,这就使得视图和控制层之间的耦合程度进一步降低。
    三个模块介绍及功能:
    Model:负责存储、检索、操纵数据。
    View:数据的展示、提供用户数据显示及操作的可视化界面,通过通过模板语法来声明在ViewModel模块完成数据绑定。
    ViewModel:处理与用户交互的负责逻辑,核心是双向数据绑定,去除了View与Model的耦合关联,View可以独立于Model变化和修改方便测试,同时降低了代码的冗余度增加了重用度。
    MVVM架构模式

    二、多层架构

    多层架构是开发人员在开发过程当中面对复杂且易变的需求采取的一种以隔离控制为主的应对策略,具体显示为将业务划分为多个层。

    2.1 3层架构(3-tier architecture)

    三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为:界面层(User Interface layer)、业务逻辑层(Business Logic Layer)、 数据访问层(Data access layer)。
    各层功能:
    UI(界面层): 数据的展示、提供用户数据显示及操作的可视化界面。用于接收用户输入的数据和显示处理后用户需要的数据。
    BLL:(业务逻辑层): UI层和DAL层之间的交互通道。对数据层的操作,对数据业务逻辑处理。
    DAL:(数据访问层): 实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层,同时将业务层处理的数据保存到数据库。
    三层架构
    大多数人三层架构易与架构模式混淆(尤其是MVC模式),从表示图可以直观看出它们间区别。架构模式(MVC)设计初衷是降低View与Model间的耦合度、降低代码冗余度、提高数据访问安全性。而三层架构是从整个业务应用出发,架构模式例如MVC只是三层架构中的UI(界面层)和BLL(业务逻辑层)展示。(很多博客文章表示MVC严格意义上 只是三层架构的UI界面层,MVC的Model模块实现了业务逻辑的处理和对数据层的操作)用图表示之间关系如下(下图表示基于B/S系统的三层架构,橙线表示对B/S系统的划分)。
    在这里插入图片描述

    2.2 多层架构(n-tier architecture)

    简单的说多层架构是对三层架构的进一步划分,实际中有时“标准”的划分为三层架构会对维护调试带来很多麻烦,多层架构便是对三层架构中的UI(界面层)与BLL(业务逻辑层)进行进一步细分。

    学期末学习了MVC架构模式有感,也算完成了自己的第一篇博客,当作知识积累日志。
    参考学习文章:https://www.runoob.com/w3cnote/three-tier-architecture.html
    参考学习文章:https://www.jianshu.com/p/ebd2c5914d20

    展开全文
  • 软件架构模式之分层架构

    万次阅读 多人点赞 2015-04-19 23:53:59
    对程序员来说很常见一种情况是在没有合理的程序架构时就开始编程,没有一个清晰的和定义好的架构的时候,大多数开发者和架构师通常会使用标准式的传统分层架构模式(也被称为多层架构)——通过将源码模块分割为几个...

    本章内容出自《软件架构模式》第一章,该书由 开发技术前线 项目组成员翻译,更多内容请访问 《软件架构模式》中文版pdf

    简介

    对程序员来说很常见一种情况是在没有合理的程序架构时就开始编程,没有一个清晰的和定义好的架构的时候,大多数开发者和架构师通常会使用标准式的传统分层架构模式(也被称为多层架构)——通过将源码模块分割为几个不同的层到不同的包中。不幸的是,这种编码方式会导致一系列没有组织性的代码模块,这些模块缺乏明确的规则、职责和同其他模块之间的关联。这通常被称为架构大泥球。

    应用程序缺乏合理的架构一般会导致程序过度耦合、容易被破坏、难以应对变化,同时很难有一个清晰的版本或者方向性。这样的结果是,如果你没有充分理解程序系统里每个组件和模块,就很难定义这个程序的结构特征。有关于程序的部署和维护的基本问题都难以回答,比如:程序架构是什么规模?应用程序有什么性能特点?应用程序有多容易应对变化?应用程序的部署特点是什么?架构是如何反应的?

    架构模式帮助你定义应用程序的基本特征和行为。例如,一些架构模式会让程序自己自然而然地朝着具有良好伸缩性的方向发展,而其他架构模式会让程序朝着高度灵活的方向发展。知道了这些特点,了解架构模式的优点和缺点是非常必要的,它帮助我们选择一个适合自己特定的业务需求和目标的的程序。

    作为一个架构师,你必须证明你的架构模式的决策是正确的,特别是当需要选择一个特定的体系结构模式或方法的时候。这本迷你书的目的就是给你足够的信息让你去做出正确的架构决策。

    第一章 分层架构

    分层架构是一种很常见的架构模式,它也叫N层架构。这种架构是大多数Jave EE应用的实际标准,因此很多的架构师,设计师,还有程序员都知道它。许多传统IT公司的组织架构和分层模式十分的相似。所以它很自然的成为大多数应用的架构模式。

    模式分析

    分层架构模式里的组件被分成几个平行的层次,每一层都代表了应用的一个功能(展示逻辑或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种,大多数的结构都分成四个层次:展示层,业务层,持久层,和数据库层。如表1-1,有时候,业务层和持久层会合并成单独的一个业务层,尤其是持久层的逻辑绑定在业务层的组件当中。因此,有一些小的应用可能只有3层,一些有着更复杂的业务的大应用可能有5层或者更多的分层。

    分层架构中的每一层都着特定的角色和职能。举个例子,展示层负责处理所有的界面展示以及交互逻辑,业务层负责处理请求对应的业务。架构里的层次是具体工作的高度抽象,它们都是为了实现某种特定的业务请求。比如说展示层并不需要关心怎样得到用户数据,它只需在屏幕上以特定的格式展示信息。业务层并不关心要展示在屏幕上的用户数据格式,也不关心这些用户数据从哪里来。它只需要从持久层得到数据,执行与数据有关的相应业务逻辑,然后把这些信息传递给展示层。

    这里写图片描述

    分层架构的一个突出特性是组件间关注点分离 (separation of concerns)。一个层中的组件只会处理本层的逻辑。比如说,展示层的组件只会处理展示逻辑,业务层中的组件只会去处理业务逻辑。多亏了组件分离,让我们更容易构造有效的角色和强力的模型。这样应用变的更好开发,测试,管理和维护。

    关键概念

    注意表1-2中每一层都是封闭的。这是分层架构中非常重要的特点。这意味request必须一层一层的传递。举个例子,从展示层传递来的请求首先会传递到业务层,然后传递到持久层,最后才传递到数据层。

    这里写图片描述

    那么为什么不允许展示层直接访问数据层呢。如果只是获得以及读取数据,展示层直接访问数据层,比穿过一层一层来得到数据来的快多了。这涉及到一个概念:层隔离。

    层隔离就是说架构中的某一层的改变不会影响到其他层:这些变化的影响范围限于当前层次。如果展示层能够直接访问持久层了,假如持久层中的SQL变化了,这对业务层和展示层都有一定的影响。这只会让应用变得紧耦合,组件之间互相依赖。这种架构会非常的难以维护。

    从另外一个方面来说,分层隔离使得层与层之间都是相互独立的,架构中的每一层的互相了解都很少。为了说明这个概念的牛逼之处,想象一个超级重构,把展示层从JSP换成JSF。假设展示层和业务层的之间的联系保持一致,业务层不会受到重构的影响,它和展示层所使用的界面架构完全独立。

    然而封闭的架构层次也有不便之处,有时候也应该开放某一层。如果想往包含了一些由业务层的组件调用的普通服务组件的架构中添加一个分享服务层。在这个例子里,新建一个服务层通常是一个好主意,因为从架构上来说,它限制了分享服务访问业务层(也不允许访问展示层)。如果没有隔离层,就没有任何架构来限制展示层访问普通服务,难以进行权限管理。

    在这个例子中,新的服务层是处于业务层之下的,展示层不能直接访问这个服务层中的组件。但是现在业务层还要通过服务层才能访问到持久层,这一点也不合理。这是分层架构中的老问题了,解决的办法是开放某些层。如表1-3所示,服务层现在是开放的了。请求可以绕过这一层,直接访问这一层下面的层。既然服务层是开放的,业务层可以绕过服务层,直接访问数据持久层。这样就非常合理。

    1-3

    开放和封闭层的概念确定了架构层和请求流之间的关系,并且给设计师和开发人员提供了必要的信息理解架构里各种层之间的访问限制。如果随意的开放或者封闭架构里的层,整个项目可能都是紧耦合,一团糟的。以后也难以测试,维护和部署。

    示例

    为了演示分层架构是如何工作的,想象一个场景,如表1-4,用户发出了一个请求要获得客户的信息。黑色的箭头是从数据库中获得用户数据的请求流,红色箭头显示用户数据的返回流的方向。在这个例子中,用户信息由客户数据和订单数组组成(客户下的订单)。

    用户界面只管接受请求以及显示客户信息。它不管怎么得到数据的,或者说得到这些数据要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求,它就会转发这个请求给用户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理对应数据(约束关系)。业务层里的customer object聚合了业务请求需要的所有信息(在这个例子里获取客户信息)。这个模块调用持久层中的 customer dao 来得到客户信息,调用order dao来得到订单信息。这些模块会执行SQL语句,然后返回相应的数据给业务层。当 customer object收到数据以后,它就会聚合这些数据然后传递给 customer delegate,然后传递这些数据到customer screen 展示在用户面前。

    这里写图片描述

    从技术的角度来说,有很多的方式能够实现这些模块。比如说在Java平台中,customer screen 对应的是 (JSF) Java Server Faces ,用 bean 组件来实现 customer delegate。用本地的Spring bean或者远程的EJB3 bean 来实现业务层中的customer object。上例中的数据访问可以用简单的POJP’s(Plain Old Java Objects),或者可以用MyBatis,还可以用JDBC或者Hibernate 查询。Microsoft平台上,customer screen能用 .NET 库的ASP模块来访问业务层中的C#模块,用ADO来实现用户和订单数据的访问模块。

    注意事项

    分层架构是一个很可靠的架构模式。它适合大多数的应用。如果你不确定在项目中使用什么架构,分层架构是再好不过的了。然后,从架构的角度上来说,选择这个模式还要考虑很多的东西。

    第一个要注意的就是 污水池反模式(architecture sinkhole anti-pattern)。
    在这个模式中,请求流只是简单的穿过层次,不留一点云彩,或者说只留下一阵青烟。比如说界面层响应了一个获得数据的请求。响应层把这个请求传递给了业务层,业务层也只是传递了这个请求到持久层,持久层对数据库做简单的SQL查询获得用户的数据。这个数据按照原理返回,不会有任何的二次处理,返回到界面上。

    每个分层架构或多或少都可能遇到这种场景。关键在于这样的请求有多少。80-20原则可以帮助你确定架构是否处于反污水模式。大概有百分之二十的请求仅仅是做简单的穿越,百分之八十的请求会做一些业务逻辑操作。然而,如果这个比例反过来,大部分的请求都是仅仅穿过层,不做逻辑操作。那么开放一些架构层会比较好。不过由于缺少了层次隔离,项目会变得难以控制。

    模式分析

    下面的的表里分析了分层架构的各个方面。

    整体灵活性

    评级:低
    分析:总体灵活性是响应环境变化的能力。尽管分层模式中的变化可以隔绝起来,想在这种架构中做一些也改变也是并且费时费力的。分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因。

    易于部署

    评级:低
    分析:这取决于你怎么发布这种模式,发布程序可能比较麻烦,尤其是很大的项目。一个组件的小小改动可能会影响到整个程序的发布(或者程序的大部分)。发布必须是按照计划,在非工作时间或者周末进行发布。因此。分层模式导致应用发布一点也不流畅,在发布上降低了灵活性。

    可测试性

    评级:高
    分析:因为组件都处于各自的层次中,可以模拟其他的层,或者说直接去掉层,所以分层模式很容易测试。开发者可以单独模拟一个展示组件,对业务组件进行隔绝测试。还可以模拟业务层来测试某个展示功能。

    性能

    评级:低
    分析:尽管某些分层架构的性能表现的确不错,但是这个模式的特点导致它无法带来高性能。因为一次业务请求要穿越所有的架构层,做了很多不必要的工作。

    伸缩性

    评级:低
    分析:由于这种模式以紧密耦合的趋势在发展,规模也比较大,用分层架构构建的程序都比较难以扩展。你可以把各个层分成单独的物理模块或者干脆把整个程序分成多个节点来扩展分层架构,但是总体的关系过于紧密,这样很难扩展。

    易开发性

    评级:容易
    分析:在开发难度上面,分层架构得到了比较高的分数。因为这种架构对大家来说很熟悉,不难实现。大部分公司在开发项目的都是通过层来区分技术的,这种模式对于大多数的商业项目开发来说都很合适。公司的组织架构和他们软件架构之间的联系被戏称为”Conway’s law”。你可以Google一下查查这个有趣的联系。

    展开全文
  • 五大主流软件架构模式1.五大主流软件架构模式2.详细介绍1.微内核模式2.微服务模式3.分层架构模式4.基于事件(事件驱动)的模式5.给予空间的模式 1.五大主流软件架构模式 微内核、微服务、分层架构、基于事件(事件驱动...

    1.五大主流软件架构模式

    微内核、微服务、分层架构、基于事件(事件驱动)和基于空间

    2.详细介绍

    首先,什么是软件架构模式?

    架构模式是那些由软件架构师通过持续实践,进而总结出的、过往已验证的、优秀设计架构。它们往往能够被重复地使用到其他项目或领域之中。更具体地说,架构模式是需要在实践中反复发掘的一组设计决策。它具有明确定义的属性,以及一套可以被重复使用与描述的架构。

    其实,开发软件架构可以被看作是针对模式进行选择、定制和组合的一整套过程。而软件架构师的任务就是要决定:如何实例化模式,如何使其与特定的上下文、以及问题的约束相适应。我们将在下文中进行详细的讨论。

    Mark Richards在其著作–《软件架构模式》一书中主要介绍了5种软件架构模式,它们分别是:微内核、微服务、分层架构、基于事件(事件驱动)和基于空间。下面

    展开全文
  • 程序员必知的几种软件架构模式

    千次阅读 多人点赞 2020-10-27 14:11:45
    程序员必知的几种软件架构模式前序分层架构模式多层模式管道 - 过滤器架构客户端 - 服务器架构模型 - 视图 - 控制器架构(MVC)事件驱动架构微服务架构 前序 架构模式是对给定上下文的软件架构中常见问题的一种通用...

    前序

    架构模式是对给定上下文的软件架构中常见问题的一种通用的可复用的解决方案。

    一种模式就是特定上下文的问题的一种解决方案。

    然而,很多开发者至今还对各种软件架构模式之间的差别搞不清,甚至对其所知甚少。

    大体上,主要有下面这几种架构模式:

    • 分层架构

    • 管道 - 过滤器架构

    • 客户端 - 服务器架构

    • 模型 - 视图 - 控制器架构

    • 事件驱动架构

    • 微服务架构

    程序员必知的几种软件架构模式

    分层架构模式

    最常见的架构模式就是分层架构或者称为 n 层架构。

    大部分软件架构师、设计师和开发者都对这个架构模式非常熟悉。尽管对于层的数量和类型没有具体限制,但大部分分层架构主要由四层组成:展现层、业务层、持久层和数据库层,如下图所示。

    一个很流行的 n 层架构示例

    一个很流行的 n 层架构示例

    上下文
    所有复杂的系统都会经历独立地发展和衍化系统各个部分的需要。出于这个原因,系统开发者需要对关注点进行清晰且条理分明的分离,以便系统的各个模块可以独立地开发和维护。

    问题
    软件需要以这样一种方式分割:各个模块可以独自开发和衍化,各自部分之间的交互非常少,支持可移植性、可修改性和复用性。

    方案
    为了实现关注点分离,分层模式将软件分割成各个单元(称为“层”)。每一层都是一组模块,提供了一组高内聚的服务。其使用必须是单向的。层将一组软件作为一个完整的分区,每个分区暴露一个公开接口。

    • 第一个概念是,每一层都有特定的角色和职责。例如,展现层负责处理所有的用户界面。分层架构的这种关注点分离,让构建高效的角色和职责非常简单。
    • 第二个概念是,分层架构模式是一个技术性的分区架构,而非一个领域性的分区架构。它们是由组件组成的,而不是领域。
    • 最后一个概念是,分层架构中的每一层都被标记为封闭或者开放。封闭层意味着请求从一层移到另一层,它必须通过它正下面的这一层才能达到下面这一层的再下一层。请求不能跳过任何层。

    在这里插入图片描述

    封闭层和请求访问

    弱点
    分层会导致性能下降。这种模式不适合高性能应用程序,因为经过架构中的多层来实现一个业务请求的效率是不高的。

    分层还会增加系统的前期成本和复杂性。

    用途
    我们应该将这种方式应用于小型简单的应用程序或网站。对于预算和时间非常紧张的场景,这是一个不错的选择。

    多层模式

    方案
    在这里插入图片描述

    一个多层模式示例:消费者网站 J2EE

    许多系统的执行结构被组织成一系列逻辑组件分组。每个分组被称为一个层。

    上下文
    在一个分布式部署中,通常需要将系统的基础设施分到不同的子集中。

    问题
    我们如何将系统分割到多个计算上独立的执行结构:由一些通信媒介连接的软件和硬件组?

    弱点
    大量前期成本和复杂性。

    用途
    用在分布式系统中。

    管道 - 过滤器架构

    软件架构中反复出现的一种模式是管道 - 过滤器(pipe-filter)模式。
    在这里插入图片描述

    管道过滤器模式

    上下文

    许多系统需要转换从输入到输出的离散数据流。许多类型转换在实践中重复出现,因此将其创建成独立的可复用的部分,这是比较理想的。

    问题

    这些系统需要被分割成可复用的松耦合的组件,组件之间拥有简单通用的交互机制。这样它们就可以灵活地相互结合。这些通用松耦合的组件就很容易复用。那些独立的组件可以并行执行。

    方案

    这种架构中的管道构成了过滤器之间的通信通道。第一个概念是,由于性能原因,每个管道都是非定向的和点对点的,接受来自一个源的输入并经常直接输出到另外一个源。

    在这种模式中,有如下四种过滤器。

    producer(source):一个过程的起点。
    transformer (map):对一些或所有数据进行转换。
    tester (reduce):测试一个或多个条件。
    consumer (sink):终点。
    

    弱点

    不太适合交互性的系统,因为它们的转换特性。

    过多的解析和反解析会导致性能损失,也会增加编写过滤器本身的复杂性。

    用途

    管道 - 过滤器架构用于各种应用程序,特别是简化单项处理的任务,例如 EDI、ETL 工具。

    编译器:连续的过滤器执行词法分析、语法分析、语义分析和代码生成。

    客户端 - 服务器架构

    在这里插入图片描述上下文

    有许多共享资源和服务是大量分布式的客户端希望访问的,我们希望控制访问或服务质量。

    问题

    通过管理一组共享资源和服务,我们可以通过分解公共服务并在单个位置或少数位置进行修改来提高可修改性和复用性。我们想要通过在将资源本身分布在多个物理服务器上的同时集中控制这些资源和服务,来提高可伸缩性和可用性。

    方案

    在客户端 - 服务器模式中,组件和连接器具有特定的行为。

    称为“客户端”的组件将请求发送到称为“服务器”的组件,然后等待回复。
    服务器组件接收到客户端的请求并向其发送回复。

    弱点

    服务器会成为性能瓶颈和单点故障位置。

    在系统建成后,关于功能位置(在客户端还是在服务器)的决策通常是复杂的而且变动成本很大。

    用途

    对于有许多组件(客户端)发送请求到另外一些提供服务的组件(服务器)的系统,我们可以使用客户端 - 服务器模式来建模这个系统的一部分:在线应用程序,例如电子邮件、共享文档或银行服务。

    模型 - 视图 - 控制器架构(MVC)

    在这里插入图片描述
    上下文

    用户界面通常是一个交互性应用程序的最频繁被修改的部分。用户通常希望从不同的视角查看数据,例如柱状图或者饼图。这些表示形式都应该反映数据当前的状态。

    问题

    用户界面功能如何独立于应用程序功能,同时还还对用户输入或底层应用程序数据的更改做出响应?

    当底层应用程序数据更改时,如何创建、维护和协调用户界面的多个视图?

    方案

    模型 - 视图 - 控制器(model-view-controller,即 MVC)模式将应用程序功能分为以下三种类型的组件:

    模型,包含应用程序的数据。
    视图,显示部分底层数据并与用户交互。
    控制器,在模型和视图之间进行中介并管理状态更改的通知。
    

    弱点

    对于简单的用户界面,其复杂性并不值得这么做。

    模型、视图和控制器抽象可能不适用于某些用户界面工具包。

    用途

    MVC 是网站或移动应用程序开发用户界面常用的一种架构模式。

    事件驱动架构

    上下文

    需要提供计算和信息资源来处理传入的应用程序生成的独立异步事件,这种方式可以随着需求的增加而扩展。

    问题

    构建分布式系统,这个系统可以服务异步到达的事件相关信息,并且能从简单小型扩展到复杂大型。

    方案
    在这里插入图片描述
    为事件处理部署独立的事件进程或处理器。到达的事件进入队列。调度程序根据调度策略从队列中拉取事件并将它们分配到合适的事件处理器。

    弱点

    性能和错误恢复可能是问题。

    用途

    使用这个方案的电商应用程序将工作如下:

    Order Service 创建一个 Order,这个订单处于待定状态,然后发布一个OrderCreated事件。

    • Customer Service 接收到这个事件并尝试为这个 Order 扣除信用。然后发布一个 Credit Reserved 事件或者CreditLimitExceeded(超出信用限额)事件。
    • Order Service 接收到 Customer Service 发送的事件并将订单状态更改为已核准或已取消。

    微服务架构

    上下文

    部署基于服务器的企业应用程序,支持各种浏览器和原生移动客户端。 应用程序通过执行业务逻辑、访问数据库、与其它系统交换信息并返回响应来处理客户端请求。这个应用程序可能会暴露一个第三方 API。

    问题

    一体化应用程序会变得过于庞大和复杂,无法得到有效支持和部署来实现最优的分布式资源利用,例如在云环境中。

    方案
    在这里插入图片描述将应用程序构建成服务套件。每个服务都是独立部署和可扩展的,拥有自己的 API 边界。不同的服务可以用不同的编程语言编写,管理它们自己的数据库,由不同的团队开发。

    弱点

    系统设计必须能容忍服务失败,需要更多的系统监控。服务编排和事件协作开销比较大。

    当然,我们还需要更多钱。

    用途

    许多使用场景都可以应用微服务架构,特别是那些涉及大量数据管道的场景。例如,一个微服务系统对关于一个公司的零售店销售的报表系统会比较理想。数据展现过程的每一步都会被一个微服务处理:数据收集、清理、规范化、浓缩、聚合、报告等。

    展开全文
  • #资源达人分享计划#
  • MVC设计模式多层架构

    千次阅读 2016-05-03 17:04:05
    MVC设计模式多层架构多层架构就拿B/S开发说起。最初的ASP直接把数据库访问代码写在页面上。整个网站就是几个页面。数据访问、业务控制、界面显示全都在一个文件里。这种设计可以理解为一层架构。因为它没有分层的...
  • 10种常见的软件架构模式

    千次阅读 2018-06-13 18:25:06
    Tips原文作者:Vijini Mallawaarachchi原文地址:10 Common Software Architectural Patterns in a nutshell有没有想过要设计多大的企业规模系统?在主要的软件开发开始之前,我们必须...什么是架构模式?根据维基...
  • 本文首先考察企业级应用的一般概念和需求,然后简要阐述面向对象程序设计的基本原则,并结合软件工程的思想来讨论多层的J2EE应用架构,分析它们满足企业级应用的方式,,再通过讲述常用的几种Java设计模式和Java反射...
  • 多层架构 分布式架构 介绍 如果您曾经在IT项目中工作过,您可能会知道分解源代码的必要性,以避免熵随着项目变得越来越大而被您所拥有……如果您曾经遇到过其中一种情况: 我从一个小项目开始,该项目一切都很好...
  • 软件分层的概念一直很模糊,也没有一个统一的标准,即使有些人明白三层架构的理念但却不会使用,不是如何创建三层架构。在网上发现了一个很不错的网站架构设计模式,分别介绍了单层架构,二层架构,三层架构,有例字...
  • 一、软件架构设计 软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件元素、元素的外部可见属性及它们之间的关系组成。 软件系统架构是关于软件系统的 结构、行为和属性 的高级抽象。指定了软件...
  • 模式实例 为更好描述分层架构怎样工作,考虑一个业务从业人员获取特定目标用户信息的需求,如图1-4所示。黑色箭头标志一路下到数据库的获取用户数据的请求流向,而红色箭头显示从下往上直到显示数据的屏幕这...
  • 分层体系结构模式是n层模式,其中组件被组织在水平层中。这是设计大多数软件的传统方法,并且具有独立性。这意味着所有组件都是互连的,但彼此之间不依赖。 图1:分层架构 在此体系结构中有四层,其中...
  • 软件架构设计之七:软件架构设计

    千次阅读 2013-08-27 20:28:13
    设计模式的概念、设计模式的组成、模式软件架构、设计模式分类、设计模式的实现。 2)系统架构设计案例分析。包括软件架构技术、XML技术、基于架构的软件开发过程、架构模型(风格)、特定领域软件架构、基于架构...
  • 多层web应用架构 介绍 由于业务文档被认为是域层的输入,因此系统 需求规范是应用层的主要输入文档。 该层的范围是提供对系统定义要求的实现。 因此,很容易理解,其中包含的大多数逻辑都是面向过程的,因此链接到...
  • 本文介绍了软件体系架构模式的层模式,分析了它的结构,特点,实现,以及优缺点等. 然后介绍遵循层模式的Architectural cube理论,结合J2EE的体系架构特点,剖析层模式是怎样应用的.最后以PetStore为例, 简单阐述怎样应用...
  • 软件架构模式,诞生于软件开发的最大难题——需求变更。由于需求变更,导致了大量项目因为超出预算的人力、时间而归于失败。软件开发成本有限的,但需求变更似乎是无限的,这成为了一个非常难解决的问题。  在...
  • 软件架构

    千次阅读 2009-06-20 02:14:00
    软件架构 软件架构:没有最好只有最适用 如何规避软件架构风险固化需求完善的业务原型完整架构规范80%的经验架构+20%的创新架构 软件架构通用的服务模式类工厂服务缓存服务(内存服务)配置服务异常处理服务日志...
  • 软件体系架构模式在 J2EE 中的应用

    千次阅读 2014-11-13 09:26:43
    层体系架构模式 层(layer)体系架构模式就是把应用系统分解成子任务组,其中每个子任务组处于一个特定的抽象层次上。 1.1 概述 层架构模式组织成一个层次结构,每一层为上层服务 (Service Provider),同时...
  • 近段时间结合自已的经验,写了一个net平台的系统架构,下面是本系统架构的主要章节,以后将以连载的方式逐步与大家共享自已经的心得体会。...1.1建立Desktop与Web共存的多层架构 1.2数据访问层 1.2.1数据访问层
  • 软件体系架构模式在J2EE中的应用 IBM

    千次阅读 2005-09-04 23:37:00
    层(Layer)模式刘兵技术顾问, 软件公司2003 年 12 月 25 日本文介绍了软件体系架构模式的层模式,分析了它的结构,特点,实现,以及优缺点等. 然后介绍遵循层模式的Architectural cube理论,结合J2EE的体系架构特点,剖析层...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 19,509
精华内容 7,803
关键字:

多层软件架构模式