App架构设计经验谈:数据层的设计

原创文章,转载请注明:转载自Keegan小钢
并标明原文链接:http://keeganlee.me/post/architecture/20160120
微信订阅号:keeganlee_me
写于2016-01-20


App架构设计经验谈:接口的设计
App架构设计经验谈:技术选型
App架构设计经验谈:数据层的设计
App架构设计经验谈:业务层的设计
App架构设计经验谈:展示层的设计


一个App,从根本上来说,就是对数据的处理,包括数据从哪里来、数据如何组织、数据怎么展示,从职责上划分就是:数据管理、数据加工、数据展示。相对应的也就有了三层架构:数据层、业务层、展示层。本文就先讲讲数据层的设计。

数据层,是三层架构中的最底层,负责数据的管理。它主要的任务就是:

  1. 调用网络API,获取数据;
  2. 将数据缓存到本地;
  3. 将数据交付给上一层。

根据这三个任务,数据层可以再拆分为三层:网络层、本地数据层、交付层。

网络层

网络层主要就是对网络API的封装。关于API的设计,该系列的第一篇文章接口的设计已经讲过一些。关于如何封装,可以参考Android项目重构之路系列的架构篇实现篇,其中接口层和本文的网络层是一样的。

还有一些在前面的文章中没有提及到的,在此做一些补充。

首先是不同网络状态的处理。当网络不可用时,则不应该再去调用API;当网络可用,但不是WIFI时,有些比较耗流量的操作也应该禁止,比如上传和下载大文件;当网络状态不同时,还可以采用不同的网络策略,比如,当网络为WIFI时,当前API可以返回更多更全面的数据,还可以预先加载相关联的其他API。

其次,为了节省流量,接口的设计上可以对数据进行简化。例如,对于一些列表类的接口,可以这么设计:只返回更新的部分,比如,上一次请求返回了10条按时间排序的数据,第一条数据为最新的,id为101,当发起下一次请求时,将101的id作为参数调用API,API查到该id,发现该id之后又新增了两条数据,API则只返回新增的这两条数据。

另外,为了保证程序的健壮性,调用API时,对入参的合法性检查也是很有必要的。而且,也应该定义好本地的错误码和错误信息,保证每个错误都能正常解析。

本地数据层

本地数据层主要就是做缓存处理,这需要设计好一套缓存策略。设计缓存策略时,有几个问题需要考虑清楚:

  1. 哪些需要缓存?哪些不需要缓存?
  2. 缓存在哪里?数据库?文件?还是内存?
  3. 缓存时间多长?

哪些需要缓存?

将所有数据都缓存是不明智的,不同的数据应该有不同的缓存策略,比如一个电商App,首页的商品列表数据应该缓存,而且缓存时间应该比较长,而每个商品的详情数据就没必要缓存或缓存时间很短。对于一份数据需不需要缓存,判断标准可以是:用户查看该数据的频率高不高?首页商品列表是用户每次启动都会看到的,而每个商品的详情用户最多只看几次。

缓存在哪里?

从内存读取数据是最快的,但内存非常有限。因此,内存一般只用来缓存使用频率非常高的数据。

文件缓存主要就是图片、音频、视频了。

数据库可以保存大量数据,主要就是用于保存商品列表、聊天记录之类的关系型数据。

然而,不管缓存在哪里,都需要限定好缓存的容量,要定期清理,不然会越积越多。

缓存时间多长?

首先,每份缓存数据都应该设置一个缓存的有效时间,有效期的起始时间以最后一次被调用的时间为准,当该数据长时间没有再被调用到时,就应该从缓存中清理掉。

缓存的有效时间应该设多长呢?可以短至一分钟,长至一星期甚至一个月,具体因数据而异。一般内存的缓存时间不宜太长,程序退出基本就要全部清理了。文件缓存可以设置保留一天或一个星期,可以每隔一天清理一次。数据库缓存再久一些也无所谓,但最好还是不要超过一个月。

交付层

交付层其实就是一个向上层开放的交互接口层,是上层向数据层获取数据的入口。上层向数据层请求数据,它是不关心数据层的数据是从缓存获取还是从网络获取的,它只关心结果,数据层能给到它想要的数据结果就OK了。因此,交付层主要就是定义一堆开放的接口或协议。

如果接口或协议非常多,那么,将接口或协议按照模块划分也是有必要的。比如微信,按模块划分有:IM、公众号、朋友圈、钱包、购物、游戏等等。模块之间应该尽量相对独立、松耦合。

写在最后

数据层如果再扩展,还可以再加入日志管理,这里就不再展开讲了。上面内容讲得也比较乱,有哪里讲得不好的地方欢迎吐槽。


扫描以下二维码即可关注订阅号。