走向ASP.NET“.NET研究”架构设计——第六章:服务层设计(中篇)

  Façade设计模式

  在SOA客户端的设计中,最常用的模式就是Façade模式了。Façade模式简化了复杂子系统的调用接口,也就说,Façade隐藏了子系统之间的复杂关系,给客户端一个简单的调用接口。 

   Façade模式的好处如下:

1. 它可以使得第三方的类库经过包装之后,通过一个简单的接口就可以调用,如下图所示。

2. 它可以通过抽象等方式来解耦其他系统之间的依赖。

3. 它可以使得各个子系统之间的调用复杂度隐藏,通过一个简单的接口就可以调用,如下图所示

  在上面的图中:

  1. 客户端调用Façade的一个简单的API来执行一个任务。客户端不知道Façade内部是如何实现的,可能只一个任务的执行涉及到很多内部子系统的交互和合作。

  2. SubSystemA和SubSystemB才是真正的任务执行者。

  下面我们就来看看客户端和服务层之间进行通信的一些模式。

  注:把这些模式讲完之后就讲一个如何使用这些模式的例子。

  Document Message和Request-Reponse模式(“文档消息模式”和”请求-响应模式”)

  在体会”文档消息模式”的好处之前,我们先来看看一种通信方式:RPC(Remote Procedure Call 远程过程调用):RPC方式通过暴露很多不同参数的API来实现提供不同服务,如下:


Customer[] RetrieveCustomers(string country);
Customer[] RetrieveCustomers (string country, string postalCode);
Customer[] RetrieveCustomers (string country, string postalCode, string street);

  上面的服务接口允许客户端通过三种方式来获取用户的信息:通过提供不同的参数来实现。这种方式的维护很难的,而且往往把客户端搞糊涂,而且服务器端可能最后向客户端暴露很多名字一样的方法,尽管可以在WCF中改变方法最后显示到客户端的名字,但是方法依然泛滥。

  “文档消息模式”可以让客户端以统一和灵活的方式和服务进行通信。“文档消息模式”把客户端把所有的请求的信息包装成为一个信息体,发送给服务端,而且服务端的接口的定义也非常的简单,如下:


Customer[] FindBy(CustomerSearchRequest request);

  这个消息体的定义如下:


public class CustomerSearchRequest
{
public string Country { get; set; }
public string PostalCode { get; set; }
public string Street { get; set; }
}

  有的时候消息体还携带其他额外的信息到服务端,如服务的版本号,验证授权标识等。当然了,这些额外的,相同的信息,我们可以定义一个请求消息的基本,然后让所有的请求消息都集成基类。

  通过使用”文档消息模式&rdq上海企业网站制作uo;,我们就解决了之前RPC的一些问题,当然服务端对消息要做一些处理的。

   ”文档消息模式”一般和”请求-响应模式”一起使用。如之前的例子,我们是直接返回了Customer的数组,其实有些时候可能不想把业务类的定义暴露出来,而且可能我们还要给客户端返回添加额外的信息,那么我们的服务端的接口定义如下:


CustomerSearchResponse RetrieveCustomers(CustomerSearchRequest request);

  其实在之前的一些章节中的代码的例子,很多都演示了这样的模式的使用。

  大家可以看看一般”文档消息模式”和”请求-响应模式”的图示:

  Reservation 模式(预约保留模式)

  一般情况下,SOA中服务器那边都是无状态的,但是可能有些时候,我们需要服务器端来保存一个长时间运行的服务的一些状态,在这段时间内,客户端可能向服务器端发送很多的请求都被当成一个事务或者一个工作单元来处理。

  Reservation模式就是来解决这样的问题的:

  1. 我们可以发送一个请求给服务器,从服务端响应中获取一个预约的唯一编号

  2. 客户端余下的请求中都带上这个编号,以便服务器那边可以把这些请求当做一个事务处理来完成。

  通常情况下,这个预约的编号是有一定的期限的,也就说,一段时间之后,这个编号在服务端那边就过期了,主要是为了避免资源的耗费以及一些安全问题。 

  我们还是看看下面的一个在线订票系统中使用“Reservation 模式”的图示:

  在上图中:

  1. 客户端首先调用ReserveTickets服务方法,并且提供一些基本的信息给服务器:订阅2张票等。

  2. 服务端的响应就返回了一个预约的Id和一个过期的时间。

  3. 客户端程序执行一个逻辑。这些逻辑可能会从涉及到把获取customer的详细信息作为订票一个处理过程,或者进行更多的复杂的客户端和服务端的交互。

  4. 最后客户端把服务端需要的信息连同预约的Id一同提交,调用PurchaseTicket方法,然后服务端就返回订票成功的编号。

  可能上面的例子不是很恰当,大家明白其中的意思就行。

  Idempotent模式(等幂模式) 

  在调用服务接口的时候,可能出现:用同样的参数来多次调用同一个服务接口,这种情况,但是可能是我们想要的,但是也可以不是我们想要的。例上海闵行企业网站设计与制作如,在订单系统上海徐汇企业网站制作中,由于某些原因,导致用户把同一个账单提交了多次(如,不小心点了多次提交按钮),那么系统中的数据就出问题。所以可以采用Idempotent模式来确保相同的参数提交多次,但是服务端只是处理一次。 

上海网站建设p>  Idempotent模式的基本思想是这样的:每一次的客户端的请求,都被赋予了一个唯一的请求标识(如,这个标识的生成规则可能是通过这个请求的一些参数做一些算法来生成)。在服务端就在一个存储区域检查这个唯一的标识时候已经被处理过了,是否有对应的响应信息,如果有,那么直接把响应信息返回;如果没有,那么处理这个请求。

  如下图所示:

  今天就写到这里,下一篇就开始利用WCF来做一个Demo了。

时间: 2024-09-21 00:34:11

走向ASP.NET“.NET研究”架构设计——第六章:服务层设计(中篇)的相关文章

ASP.NET2.0自定义控件组件开发 第六章 深入讲解控件的属性

原文:ASP.NET2.0自定义控件组件开发 第六章 深入讲解控件的属性                                         深入讲解控件的属性持久化(一) 系列文章链接: ASP.NET自定义控件组件开发 第一章 待续 ASP.NET自定义控件组件开发 第一章 第二篇 接着待续 ASP.NET自定义控件组件开发 第一章 第三篇 ASP.NET自定义控件组件开发 第二章 继承WebControl的自定义控件 ASP.NET自定义控件组件开发 第三章 为控件添加事件 前

走向ASP.NE“.NET研究”T架构设计——第七章:阶段总结,实践篇(中篇)

服务层(中篇) 上一篇文章中,我们已经讲述了业务逻辑层和数据访问层层的设计和编码,下面我们就来讲述服务层的设计.如我们之前所讨论的:服务层想客户端暴露简单易用的API. 如下图所示: 在上图中: 1. ASPPatterns.Chap6.EventTickets.Contract: 这个类库中定义了服务层的接口契约. 2. ASPPatterns.Chap6.EventTickets.Service:这个类库中包含了上面接口契约的实现类以及业务逻辑的协调和数据的持久化和返回数据 3. ASPPa

走向ASP.NET架构设计第六章:服务层设计(前篇)

本篇主要是为后文做铺垫,所以理论的东西相对而言比较的多一点! 服务层的概述 首先解释一下什么是"服务Service",从广义来讲:只要是你使用了别人的东西,那么你就在使用别人提供的服务.在这里,服务就是指可能被一个或者多个系统使用的核心的业务逻辑,我们可以把服务简单的想象成为一些可供调用的API. 在之前的第四章中,我们讲述了如何组织业务逻辑,第五章讲述了在业务层的设计中可以采用的一些模式.但是还有一个问题需要大家考虑的是:如何把业务层提供给其他的层来调用? 可能认为这个问题有莫名奇妙

一起谈.NET技术,走向ASP.NET架构设计——第六章:服务层设计(前篇)

本篇主要是为后文做铺垫,所以理论的东西相对而言比较的多一点! 服务层的概述 首先解释一下什么是"服务Service",从广义来讲:只要是你使用了别人的东西,那么你就在使用别人提供的服务.在这里,服务就是指可能被一个或者多个系统使用的核心的业务逻辑,我们可以把服务简单的想象成为一些可供调用的API. 在之前的第四章中,我们讲述了如何组织业务逻辑,第五章讲述了在业务层的设计中可以采用的一些模式.但是还有一个问题需要大家考虑的是:如何把业务层提供给其他的层来调用? 可能认为这个问题有莫名奇妙

走向ASP.NET架构设计第六章:服务层设计(中篇)

Façade设计模式 在SOA客户端的设计中,最常用的模式就是Façade模式了.Façade模式简化了复杂子系统的调用接口,也就说,Façade隐藏了子系统之间的复杂关系,给客户端一个简单的调用接口.  Façade模式的好处如下: 1. 它可以使得第三方的类库经过包装之后,通过一个简单的接口就可以调用,如下图所示. 2. 它可以通过抽象等方式来解耦其他系统之间的依赖. 3. 它可以使得各个子系统之间的调用复杂度隐藏,通过一个简单的接口就可以调用,如下图所示 在上面的图中: 1. 客户端调用F

走向ASP.NET架构设计第七章:阶段总结,实践篇(中篇)

服务层(中篇) 上一篇文章中,我们已经讲述了业务逻辑层和数据访问层层的设计和编码,下面我们就来讲述服务层的设计.如我们之前所讨论的:服务层想客户端暴露简单易用的API. 如下图所示: 在上图中: 1. ASPPatterns.Chap6.EventTickets.Contract: 这个类库中定义了服务层的接口契约. 2. ASPPatterns.Chap6.EventTickets.Service:这个类库中包含了上面接口契约的实现类以及业务逻辑的协调和数据的持久化和返回数据 3. ASPPa

一起谈.NET技术,走向ASP.NET架构设计——第七章:阶段总结,实践篇(中篇)

服务层(中篇) 上一篇文章中,我们已经讲述了业务逻辑层和数据访问层层的设计和编码,下面我们就来讲述服务层的设计.如我们之前所讨论的:服务层想客户端暴露简单易用的API. 如下图所示: 在上图中: 1. ASPPatterns.Chap6.EventTickets.Contract: 这个类库中定义了服务层的接口契约. 2. ASPPatterns.Chap6.EventTickets.Service:这个类库中包含了上面接口契约的实现类以及业务逻辑的协调和数据的持久化和返回数据 3. ASPPa

一起谈.NET技术,走向ASP.NET架构设计——第四章—业务层分层架构(中篇)

在上一篇文章中,我们讨论了两种组织业务逻辑的模式:Transaction Script和Active Record.在本篇中开始讲述Domain Model和Anemic Model. Domain Model 在开发过程中,我们常常用Domain Model来对目标的业务领域建模.通过Domain Model建模的业务类代表了目标领域中的一些概念.而且,我们会看到通过Domain Model建模的一些对象模拟了业务活动中的数据,有的对象还反映了一些业务规则. 我们就来看看电子商务系统的开发,在

一起谈.NET技术,走向ASP.NET架构设计——第二章:设计/ 测试/代码

再次申明一下:本系列不是讲述TDD的,只是用TDD来建立设计的思想.即便是用DDD,有时候还是结合TDD一起使用的. 开发方式比较 我们用下面的一段分析来引出今天的内容: 想想我们平时是如何在写代码:拿来需求,分析功能,编写功能代码.这样的方式,没有问题,大家也一直沿用很多年了.为了后面描述方便,我们称这种方式为传统流程. TDD的怎么做的: 拿来需求,分析功能,写功能测试代码,编写功能代码.其实两个过程差不多的,真的差不多的. 首先来分析下两种开发流程.个人认为:因为TDD多了一个角色转换的过