對於客戶端應用程式,免不了和遠端服務打交道。設計一個良好的『服務層』能幫我們規範和分離業務程式碼,提高生產效率。服務層最核心的模組一定是怎樣傳送請求,雖然Mono提供了很多C#網路請求類,諸如WebClientHttpWebRequest,但考慮到跨平臺,這些類不一定適用。不過不用擔心,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上,點選此瞭解