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

走向.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了。