因为https://blog.csdn.net/urdfmqcul2/article/details/78788962
，博客搬家至https://juejin.im/user/59fd6315f265da4321536990
注：本文中所采用的架构模式基于limboy设计的<MVVM without ReactiveCocoa>
目前项目中，网络相关的功能采用的是这样一个架构（基于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来区分网络请求成功和异常的逻辑（妈妈再也不用担心看不懂别人的代码了~）
以上。
