iOS网络层设计感想

App的开发无外乎从网络端获取数据显示在屏幕上,数据做些缓存或者持久化,所以网络层极为重要。原来只是把AFNetwork二次封装了一下,使得调用变得很简单,并没有深层次的考虑一些问题。

前言

参考:
网络层设计方案
这篇文章提的问题也正是我平时经常纠结的,但是一直没有深入思考。文章给的解决方案和为什么这样做让人茅塞顿开。以下主要就是我的观后感。

三个问题

  • 使用哪种交互模式来跟业务层做对接?
  • 是否有必要将API返回的数据封装成对象然后再交付给业务层?
  • 使用集约化调用方式还是离散型调用方式去调用API?

我的设计

基本上每个网络层都会涉及到这三个问题。
我原先的设计是:

//APIClient.h
@interface APIClient : AFHTTPSessionManager

+ (instancetype)sharedRequestDataClient;

/*
 * 用json格式(POST)
 */
+ (void)requestDataPostMethodWithHTTPPath:(NSString *)path
                     parameters:(NSDictionary *)parameters
                        success:(RequestSuccessBlock)success
                        failure:(RequestFailureBlock)failure;
/*
 * 用json格式(GET)
 */
+ (void)requestDataGetMethodWithHTTPPath:(NSString *)path
                     parameters:(NSDictionary *)parameters
                        success:(RequestSuccessBlock)success
                        failure:(RequestFailureBlock)failure;

@end

//APIManager.h(一个个具体的请求,有多少个请求就有多少个方法)
@interface APIManager : NSObject

/**
 *  获取用户信息
 */
+ (void)requestUserInfoWithSuccess:(RequestSuccessBlock)success failure:(RequestFailureBlock)failure;

...
@end

@implementation APIManager

/**
 *  获取用户信息
 */
+ (void)requestUserInfoWithSuccess:(RequestSuccessBlock)success
                           failure:(RequestFailureBlock)failure { 
    [APIClient requestDataGetMethodWithHTTPPath:kUserInfo parameters:nil success:success failure:failure];
}

...
@end

APIClient继承AFHTTPSessionManager,里面做了些设置,比方说统一用json,就两个方法,get,post请求。
本来还有上传下载数据两个方法,后来所有的资源文件放阿里云上,重建了个APIOSSClient类来处理。
APIManager具体处理一个个请求,有多少请求,他就有多少方法。由它来调用APIClient。

我的回答

  • 数据的传递方式:Block。
  • 交付什么样的数据:NSDictionary,在Block回调里把字典处理成最终需要的数据,大多数情况下是model,在model里会有数据处理。
  • APIClient是集约型,很不方便,加了个APIManager,实现离散型的调用,也就是加了个离散型调用的壳。

作者的建议

  • 数据的传递方式:Delegate。
  • 交付什么样的数据:不作处理,添加了reformer(名字而已,叫什么都好),用于封装数据转化的逻辑。
  • 离散型的API调用方式。

感想

看了作者的思路和源码,发现作者考虑的问题也都想到了,但是处理的方式有很大的问题。

传递方式和调用方式

最早我接手项目的时候,只有APIClient,简单地做AFNetwork做了封装,属于集约型API调用方式,用block回调是正常的。
后来发现集约型API调用方式的弊端太多了,于是我加了个APIManager,规定所有的请求必须在里面加个方法,算是加了个离散调用的壳。但是最后APIManager太大了,好多方法,维护起来好累。
所以调用的方式还是离散型的好,因为是离散型的,所有Delegate比Block好。

作者一个API对应于一个APIManager,更加容易维护。好处非常多。

传递数据

对于应该传什么数据,其实我们的理想情况是希望API的数据下发之后就能够直接被View所展示。首先要说的是,这种情况非常少。另外,这种做法使得View和API联系紧密,也是我们不希望发生的。
这是作者的想法,我们也发现了这个问题,所以会单独在写个类处理,或者转成model,在model里处理,最终变成view需要的数据。如果是model,为了不让view和model耦合,又加了个category传数据。

而作者加了个reformer统一处理,并且作者强调去model化,从根源解决了转化成本高,model和view耦合等问题。

细节就不讲了,作者开源的网络层很cool,除了使用起来非常方便,功能还非常全,全方面覆盖。小伙伴们自己去学习吧。

作者:levi
comments powered by Disqus