Unity應用架構設計(11)——一個網絡層的構建

對於客戶端應用程序，免不了和遠程服務打交道。設計一個良好的『服務層』能幫咱們規範和分離業務代碼，提升生產效率。服務層最核心的模塊必定是怎樣發送請求，雖然Mono提供了不少C#網絡請求類，諸如WebClient，HttpWebRequest，但考慮到跨平臺，這些類不必定適用。不過不用擔憂，Unity 5.x提供了新的與網絡相關類UnityWebRequest用來替代原先的WWW，這是官方推薦的，也是最佳選擇。

使用Token進行身份驗證

首先咱們必需要考慮的是，怎樣和Web服務安全的通訊。沒錯，確定是身份驗證（Authentication）。對於像WebClient這些類，它們會提供一個屬性，好比Credentials，能夠在此屬性設置一些身份驗證信息，好比用戶名，密碼，域。這是一個很『重』的解決方案，且不管是否能在Unity中實現，單從密碼這個角度，不少遊戲根本不須要密碼。因此，咱們須要一種『輕』量級的身份驗證機制，這就是Token，中文翻譯叫『令牌』。

Token有兩個重要的特色：

• 表明了惟一的身份驗證令牌
• 具備時效性

第一點咱們確定能夠理解，惟一性是身份驗證的的基礎。那第二點怎麼理解呢？其實，Token本質上是一串加密事後的字符串，若是沒有時效性，萬一被竊取以後，他人很容易進行僞造。因此，易變的Token必定比不變的安全，你須要一個算法來動態生成Token，我提供一個簡單的算法：

md5(((day*10) + (month*100) + (last2DigitsofYear)*1000)+userId+deviceId)複製代碼

同理，你須要在Web服務前加上一個過濾器，同樣的算法來驗證Token是否一致。

Request Pipeline

Pipeline是管道的意思，管道是相連的，表明了請求的流轉。因爲UnityWebRequest必須配合StartCoroutine，而StartCoroutine又屬於View層的代碼，這和分層（詳見以前的文章）衝突，MVVM框架須要將業務邏輯從View解耦。一個比較好的解決方案是經過中介的HttpTool來解決，它是一個單例的MonoBehaviour，而且不會隨着場景的加載被銷燬。

public class HttpTool : Singleton<HttpTool>
{
    // 沒法在外界使用構造函數，確保Singleton
    protected HttpTool() { }
}複製代碼

不論是請求仍是響應，本質上是一堆數據的集合，將這些數據封裝成對象的形式會更加容易管理，我將請求相關的數據封裝成HttpRequest對象：

public class HttpRequest {
    public string Url { get; set; }
    public HttpMethod Method { get; set; }
    public string Parameters { get; set; }
}複製代碼

而將從Web服務返回的數據封裝成HttpResponse對象：

public class HttpResponse
{
    public bool IsSuccess { get; set; }
    public string Error { get; set; }
    public long StatusCode { get; set; }
    public string Data { get; set; }
}複製代碼

值得注意的是，對應Http請求，不論Get仍是Post都會將參數組裝成「field1=value1&field2=value2」格式，不一樣的是Get請求，參數會跟在Url後，而Post請求則在Request Body裏。因此須要一個幫助類，反射要傳遞的對象屬性，拼裝返回字符串。

核心的請求交由UnityWebRequest實現，經過yield等待返回的結果：

using (var www = UnityWebRequest.Get(url + parameters))
{
    yield return www.Send();
    var response = new HttpResponse
    {
        IsSuccess = !www.isError, Error = www.error, StatusCode = www.responseCode, Data = www.downloadHandler.text
    };
    onComplete(response);
}複製代碼

最後再對返回的Json字符串反序列化成對象，值得注意的是，在此我用了內置的JsonUtility類，它並不能直接反序列化一個Json數組 ，而是須要將它包裝成一個對象 ，經過集合類型屬性的形式間接被反序列化。

至此，一個完整的Request Pipeline 以下圖所示：

request_pipeline

使用策略模式加強RemoteRepository

因爲JsonUtility的限制因素多，你可能使用其餘第三方的庫。又或者不反序列化Json，而是Xml。因此在RemoteRepository中不該該限制死反序列化的代碼，更好的想法是經過『策略模式』，交由外部算法來實現。這樣的好處是你根本不須要改動RemoteRepository裏的代碼，這也符合『開閉原則』。

因此，你須要在RemoteRepository定義一個序列化接口：

public ISerializer Serializer { get; set; }複製代碼

而後，對返回的HttpResponse中的Json反序列化：

Serializer.Deserialize<R>(httpResponse.Data)複製代碼

真正的對Json序列化器實現了ISerializer接口，以策略的形式存在:

public class SerializerJson:ISerializer
{
    public static readonly SerializerJson Instance=new SerializerJson();
    private SerializerJson()
    {

    }
    public string Serialize<T>(T obj, bool readableOutput = false) where T : class, new()
    {
        throw new NotImplementedException();
    }

    public T Deserialize<T>(string json) where T : class, new()
    {
        return JsonUtility.FromJson<T>(json);
    }
}複製代碼

策略模式在編程領域運用很是廣，好比Java或者.NET框架裏的集合排序，大量用到策略模式。由程序員指定的算法來最終實現排序。

小結

本文的核心思想就是如何在合理分層結果下構建一個好用的服務層。談到了如何動態生成Token來實現身份驗證，以及分層狀況下的請求流程。對於2D而且以數據綁定爲基礎的遊戲，我認爲這是一個好的實踐方案。由於不論是三層架構仍是N層架構，經過分層的好處是更加清晰去實現業務邏輯。
源代碼託管在Github上，點擊此瞭解

歡迎關注個人公衆號：