记一次网络模块的小规模重构

因为https://blog.csdn.net/urdfmqcul2/article/details/78788962
，博客搬家至https://juejin.im/user/59fd6315f265da4321536990

注：本文中所采用的架构模式基于limboy设计的

目前项目中，网络相关的功能采用的是这样一个架构（基于MVVM），：

网络请求分层架构

1.V/VC通过执行ViewModel中的MGJCommand属性的execute方法发起一次网络请求，并且通过KVO监听网command的result来处理结果，以下以用户登录这样一个业务场景来举例：

    @weakify(self)
    [self mgj_observe:self.loginViewModel.loginCommand keyPath:@"result" block:^(MGJCommandResult* result) {
        @strongify(self)
        //判断服务端返回的状态码是否为请求成功
        if (result.error.code == SNHttpRespondCodeSuccess)
        {
            [self back];
        }
        else
        {
            //统一的显示请求错误的处理
            [SVProgressHUD showWithHttpCode:result.error.code];
        }
    }];

2.ViewModel中通过调用SNHttpManager发起网络请求操作，并对返回的SNRespond做一些数据的本地处理，并通知V/VC：

 _loginCommand = [[MGJCommand alloc] initWithConsumeHandler:^(id input, MGJCommandCompletionBlock completionBlock) {
        SNLoginRequest *request = [[SNLoginRequest alloc] init];
        [request requestRespondBlock:^(SNLoginRespond *respond) {
            completionBlock([NSError errorWithDomain:@"" code:respond.code userInfo:nil], nil);
        }];
        [[SNHttpManager sharedManager] requestAsync:request];
    }];

3.SNHttpManager是一个单例，通过将SNRequest的子类（内部封装了这个请求的地址、参数、请求方式等）传递给实际的网络库（AFNetWorking/ASI等，我们项目中采用的是基于NSURLSession实现的一个自定义库），发送HTTP请求，并将服务器返回的数据/错误/状态，序列化到SNRespond的子类中（默认是json数据的处理，封装了json的model化），最后通知viewmodel请求结束：

               request.repondBlock(respond);

这里这个repondBlock即处理网络回调的block。

很标准化的一个网络层的架构方案，但是在实际的使用过程当中，却有些别扭：

1.ViewModel通知V/VC的方式不统一

MGJCommand提供的回调方式是使用block，MGJCommandCompletionBlock中包含两个参数，一个id类型的error和一个id类型的content，由于在开发时并没有定义什么规范，所以业务实现的同学便按照自己觉得合适的方式去回调通知VC了，有的通过content参数来传递一个bool，有的通过error来传递一个bool，等等，所以说id类型的参数有时候提供了方便的同时也带来了麻烦。

2.处理网络请求异常的代码冗余

对每一个请求来说，都会出现至少三种情况：
a.请求成功；
b.网络出错，请求失败；
c.业务逻辑出错（密码错误，参数错误等），服务端返回错误码；
其中b和c，由于我们在SNHttpManager中做了处理，将网络错误的code和服务器业务错误的code统一成了一个枚举定义，对这个架构的网络发起者来说，b和c是同一个情况，统一为网络请求异常。但是需要在每个请求的调用者也就是V/VC处去判断code来决定是按a还是b/c的逻辑来处理，导致几乎每个请求处都重复地写了同样的处理网络异常的代码（根据code弹浮窗显示异常信息）。

解决方案：

首先解决问题2，由于SNHttpManager这个类本身就是跟业务有一定的耦合，因此在上述的第三部，将服务端返回数据处理成respond后，回调的block拆分成成功和失败两种状态，对应的即前面提到的a和b/c两种情况。

这样将业务的成功和失败的判断统一至了更下层的SNHttpManager中，简化了上层的代码：

            if (respond.code == SNHttpRespondCodeSuccess)
            {
                if (respond.request.successRespondBlock)
                {
                    respond.request.successRespondBlock(respond);
                    respond.request.successRespondBlock = nil;
                    
                }
            }
            else
            {
                if (respond.request.failureRespondBlock)
                {
                    respond.request.failureRespondBlock(respond);
                    respond.request.failureRespondBlock = nil;
                }
            }

此外，给SNHttpManager设置一个默认处理b/c情况的接口，我在这里使用了一个block，这样可以在程序启动的时候初始化好这个block：

    [SNHttpManager sharedManager].defaultErrorCodeHandler = ^(SNHttpRespondCode code){
        //根据不同的网络code显示对应的浮窗提示
        [SNProgressHUD showWithHttpCode:code];
    };

然后在SNHttpManager中调用这个block：

            if (respond.code == SNHttpRespondCodeSuccess)
            {
                if (respond.request.successRespondBlock)
                {
                    respond.request.successRespondBlock(respond);
                    respond.request.successRespondBlock = nil;
                    
                }
            }
            else
            {
                if (self.defaultErrorCodeHandler)
                {
                    self.defaultErrorCodeHandler(respond.code);
                }
                if (respond.request.failureRespondBlock)
                {
                    respond.request.failureRespondBlock(respond);
                    respond.request.failureRespondBlock = nil;
                }
            }

对于一些特殊的请求，不想执行这个默认处理异常状态的操作怎么办，好解决，给request加一个bool属性来区分即可：

if (!respond.request.shouldHandleErrorCode && self.defaultErrorCodeHandler)
{
    self.defaultErrorCodeHandler(respond.code);
}

这样对于V/VC这一层的调用者，就除非有额外的需要考虑的网络异常处理逻辑，一般情况下就只需要处理网络请求成功后的业务逻辑即可（好幸福~~~~）。

问题2解决了，问题1也就好办了，由于底层的SNHttpManager已经将业务逻辑判断消化掉了，针对VM回调至V/VC方式混乱不统一的问题，在以前使用KVO方式监听command的result变化之上再封装一层，这里我给MGJCommand的category中增加了一个方法：

- (void)handleSuccessResult:(MGJCommandCompletionBlock)successHandler failureResult:(MGJCommandCompletionBlock)failureHandler
{
    [self mgj_observe:self keyPath:@"result" block:^(MGJCommandResult *result) {
        if (result.error)
        {
            if (failureHandler)
            {
                failureHandler(result.error, result.content);
            }
        }
        else
        {
            if (successHandler)
            {
                successHandler(result.error, result.content);
            }
        }
    }];
}

将判断逻辑直接封装起来，强制性要求上层业务实现的同学通过block来区分网络请求成功和异常的逻辑（妈妈再也不用担心看不懂别人的代码了~）

以上。