App开发基本离不开网络请求，网络层应该怎么去搭建才能更方便使用、更专注于业务逻辑？
自个儿琢磨了一段时间，也参考了一些博客和开源框架，于是有了以下的网络层架构图。主要包含2大块，缓存层和网络请求层。
StructureFlow.png
缓存层
大部分App都会针对某些接口设计缓存。
一方面是为了在无网络或网络请求失败的时候有数据展示，而不是空白一片，这样用户体验会更好；
另一方面是为了节省资源，如果本身接口的数据更新不频繁的，没必要每次都去发起网络请求去服务器取数据，只需读缓存就可以了，例如省市区数据。
针对以上问题，我想不如每个接口都设计2个缓存配置项，一个用于配置是否需要缓存数据，另一个配置缓存过期时间。
在缓存有效时间内发起的网络请求，底层不会真正发起网络请求，只是去读取缓存数据然后返回结果。
如果缓存过期时间配置是永久有效的，则先读取缓存数据，然后发起网络请求，会回调2次。这种配置主要是为了在无网络或者是网络请求失败的时候有数据展示。
在框架中，我使用了开源库 SPTPersistentCache, 它是LRU缓存设计，可以设置缓存数据有效时间和缓存自动回收。
网络请求层
这是核心层，里面包含网络监测、JSON数据转化和缓存处理。
每一次请求都会先检查网络是否连接，如果无网络，直接返回错误。
如果网络请求失败，例如网络超时或者是服务器错误，则会返回错误。
当网络请求成功并有数据返回时，会判断当前请求是否有设置缓存，如果有则会先把数据缓存起来，然后回调成功结果。
网络请求是封装开源框架 AFNetwoking，请求参数是以NSDictionary 格式传入，返回的则是JSON数据。
我觉得请求参数以字典的形式很不方便，写起来麻烦，维护起来也麻烦，如果某个接口参数变了，需要找到那个网络发起的位置，然后修改字典的key。
针对以上问题，我利用开源框架 MJExtension，把每个接口的参数以数据Bean的形式管理，一个接口对应一个Bean。发起网络请求的时候只需传入这个Bean的实例，网络层会在里面转成字典形式，然后发起请求。
另外一个是网络返回的JSON数据，如果我们每次都需要在业务层对返回的JSON数据进行转化，这样重复代码很多，写起来也不方便。
针对此问题，我在网络层里面把返回的JSON数据利用框架 MJExtension 转成数据Bean，然后返回给业务层，这样业务层拿到就可以用了，方便。
总结
总的来说，就是把数据的处理合并在一起，在业务层直接拿就可以了。
以上是我对网络层的一些思考，不足之处，还请多多指教。
网友评论