走向ASP.NET架構設計——第六章：服務層設計（中篇）

作者: 小洋（燕洋天) 來源: 博客園發布時間: 2010-12-12 20:52 閱讀: 802 次推薦: 1 原文鏈接 [收藏]

摘要：上一篇文章介紹了一些服務層的基本知識，而且也簡要的介紹了SOA的有關知識，本篇主要是介紹在服務層可以采用的一些模式。

　　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模式的基本思想是這樣的：每一次的客戶端的請求，都被賦予了一個唯一的請求標識（如，這個標識的生成規則可能是通過這個請求的一些參數做一些算法來生成）。在服務端就在一個存儲區域檢查這個唯一的標識時候已經被處理過了，是否有對應的響應信息，如果有，那么直接把響應信息返回；如果沒有，那么處理這個請求。

　　如下圖所示：