Unity应用架构设计：一个网络层的构建

阅读目录

• 使用Token进行身份验证

• Request Pipeline

• 使用策略模式增强RemoteRepository

• 小结

对于客户端应用程序，免不了和远程服务打交道。设计一个良好的『服务层』能帮我们规范和分离业务代码，提高生产效率。服务层最核心的模块一定是怎样发送请求，虽然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 如下图所示：

使用策略模式增强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上，点击此了解