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

　　前言：上一篇文章介绍了一些服务层的基本知识，而且也简要的介绍了SOA的有关知识，本篇主要是介绍在服务层可以采用的一些模式。

本篇议题如下：

Façade 模式

Document Message和Request-Reponse模式

Reservation 模式

Idempotent模式

　　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; }
}

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

通过使用”文档消息模式”，我们就解决了之前RPC的一些问题，当然服务端对消息要做一些处理的。

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

CustomerSearchResponse RetrieveCustomers(CustomerSearchRequest request);

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

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

　　Reservation 模式(预约保留模式)

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

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

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

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

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

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

　　在上图中：

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

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

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

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

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

Idempotent模式(等幂模式)

　　在调用服务接口的时候，可能出现：用同样的参数来多次调用同一个服务接口，这种情况，但是可能是我们想要的，但是也可以不是我们想要的。例如，在订单系统中，由于某些原因，导致用户把同一个账单提交了多次（如，不小心点了多次提交按钮），那么系统中的数据就出问题。所以可以采用Idempotent模式来确保相同的参数提交多次，但是服务端只是处理一次。

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

　　如下图所示：

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

©著作权归作者所有：来自51CTO博客作者yanyangtian的原创作品，如需转载，请注明出处，否则将追究法律责任

SOA 模式小洋走向.NET架构设计

微博 QQ 微信

上一篇：走向.NET架构设计—第五章—业... 下一篇：“一点一点”成功

yanyangtian

99篇文章，109W+人气，17粉丝

关注

Ctrl+Enter 发布

发布

取消

猜你喜欢

我的友情链接这个时代会残酷惩罚不肯改变的人简述centOS 7系统用户和组的管理及配置解析DELL R710服务器迁移操作内容开学季出大事：某教育局丢失3台虚拟机 EVA4400存储虚拟机+数据库数据恢复成功案例服务器数据恢复通用方法+服务器分区丢失恢复案例在CentOS7上部署squid缓存服务器及代理功能 EMC 5400服务器raid阵列瘫痪数据恢复成功案例服务器数据恢复案例 / raid5阵列多块硬盘离线处理方法华为存储服务器卷丢失数据恢复成功案例斐讯K3C路由器无需刷机用vlmcsd搭建KMS服务器激活Windows&office 高校服务器虚拟化——高校数据中心建设【长文+图片】HP FC MSA2000服务器瘫痪数据恢复过程服务器断电瘫痪数据丢失后恢复数据的过程华为5800服务器raid阵列数据恢复成功案例【长文慎点】IBM X3850服务器删除并重建虚拟机恢复过程 HP EVA4400服务器RAID信息丢失数据恢复方法 Apache 工作模式的优化深入部署PXE远程安装服务并实现Kickstart无人值守安装

扫一扫,领取大礼包

关注

yanyangtian

转载于:https://blog.51cto.com/yanyangtian/442638