iOS开发-去model化开发

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