美文网首页
iOS开发-去model化开发

iOS开发-去model化开发

作者: Mcyboy007 | 来源:发表于2017-03-12 20:28 被阅读0次

    1.为什么不使用数据对象

    问题来源:

    • 修改某一领域共享对象或参数时,可能影响其他领域
    • 解决某一问题,如果引入某个充满各种不同问题领域的函数集,实质上也就引入了对不同问题领域解决方案的依赖

    2.去model化的手段

    a.字典流,即使用原生的数据流,通过NSDictionary方式传递

    b.reformer(本文重点)

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

    大多数App在网络层采用的方式:Delegate、Notification、Block,建议使用Delegate,理由如下:

    i.尽可能减少跨层数据交流的可能,限制耦合
    ii.统一回调,便于调试和维护
    iii.在跟业务层对接的部分只采用一种对接手段,限制灵活性,来交换应用的可维护性

    ** 什么是跨层数据交流? **
    --- 就是某一层(或模块)跟另外的与之没有直接对接关系的层(或模块)产生了数据交换。

    ** 为什么这种情况不好? **
    --- 这会导致代码混乱,破坏模块的封装性。

    ** 我们做分层架构的目的 **
    --- 其中之一就在于** 下层对上层有一次抽象,让上层可以不必关心下层细节而执行自己的业务 **。如果下层细节被跨层暴露,一方面你很容易因此失去邻层对这个暴露细节的保护;另一方面,你又不可能不去处理这个细节,所以处理细节的相关代码就会散落各地,最终难以维护

    ** Notification **
    --- 使用Notification给跨层数据交流开了一道口子,相关处理的代码不能保证都在唯一的地方。不过,在属于它的问题领域中,这也是一种非常好的解决方案

    ** Block **
    --- 很难追踪,难以维护。block会延长相关对象的生命周期。block在离散型场景下不符合使用的规范。

    当回调之后要做的任务在每次回调时都是一致的情况下,选择delegate,在回调之后要做的任务在每次回调时无法保证一致,选择block。在** 离散型调用的场景 下,每一次回调都是能够保证任务一致的,因此适用delegate。 苹果原生的网络调用 采用delegate,因为苹果是基于离散模型去设计网络调用的。在 集约型调用的场景 下,使用block是合理的,因为每次请求的类型都不一样,那么自然回调要做的任务也都会不一样。 AFNetworking 就是属于集约型调用,因此它采用了block来做回调。
    在网络请求和网络层接受请求的地方时,使用Block没问题。但是在获得数据交给业务方时,最好还是通过Delegate去通知到业务方。我们实际编码时也会意识到尽可能让
    Block的回调着陆点统一 **,所以选择在block里面写个一句话的方法接收参数,然后做转发,然后就可以把这个方法放在其他地方,这实质上跟使用Delegate的手段没有什么区别,只是绕了一下,不过还是没有解决统一回调方法的问题,因为block里面写的方法名字可能在不同的ViewController对象中都会不一样,所以,建议的写法如下:

    [AFNetworkingAPI callApiWithParam:self.param successed:^(Response *response){
            if ([self.delegate respondsToSelector:@selector(successWithResponse:)]) {
                [self.delegate successedWithResponse:response];
            }
        } failed:^(Request *request, NSError *error){
            if ([self.delegate respondsToSelector:@selector(failedWithResponse:)]) {
                [self failedWithRequest:request error:error];
            }
        }];
    
    1.1小结:以什么方式将数据交付给业务层?

    尽可能通过Delegate的回调方式交付数据,这样可以避免不必要的跨层访问。当出现跨层访问的需求时(比如信号类型切换),通过Notification的方式交付数据。正常情况下应该是避免使用Block的

    1.2 交付什么样的数据给业务层?

    大部分的做法是:将拿到的JSON数据,转变成对应的对象模型,这么做有如下成本:

    1.数组内容转化成本高
    2.存在需要2次转化的数据
    3.只有API返回的数据高度标准化时,生成的Model的可复用性才高
    4.调试时,Model的展示不如NSDictionary/NSArray直观
    5.同一个API的数据被不同的View展示,难以控制数据转化的代码,有可能散落在多个地方

    1.2小结:交付什么样的数据给业务层

    对于业务层而言,由Controller根据View和APIManager之间的关系,选择合适的reformer将View可以直接使用的数据(甚至reformer可以用来直接生成view)转化好之后交付给View。对于网络层而言,只需要保持住原始数据即可,不需要主动转化成数据原型。然后数据采用NSDictionary加Const字符串key来表征,避免了使用对象来表征带来的迁移困难,同时不失去可读性

    参考资料:
    http://casatwy.com/OOP_nomodel.html

    相关文章

      网友评论

          本文标题:iOS开发-去model化开发

          本文链接:https://www.haomeiwen.com/subject/eowcwttx.html