Unity应用架构设计(11)——一个网络层的构建-阿里云开发者社区

开发者社区> 长征6号> 正文

Unity应用架构设计(11)——一个网络层的构建

简介:
+关注继续查看

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

88x31.png
本博客为木宛城主原创,基于Creative Commons Attribution 2.5 China Mainland License发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名木宛城主(包含链接)。如您有任何疑问或者授权方面的协商,请给我留言。

本文转自木宛城主博客园博客,原文链接:http://www.cnblogs.com/OceanEyes/p/building_service_layer.html,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
OneAlert携手钉钉快速构建IT运维on-call机制
摘要:OneAlert 是北京蓝海讯通科技股份有限公司旗下产品,中国第一个 SaaS 模式的免费的云告警平台,集成国内外主流监控/支撑系统,实现一个平台上集中处理所有IT事件,提升IT可靠性。并且能够帮助中小企业快速构建 IT 运维 7x24 小时的 on-call 机制,随时响应解决故障/问题。
4043 0
+关注
1224
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载