粗略地在iOS中使用URLManager架构

最近粗略的学习了一些iOS架构，本文算是对最近学习的一些总结，并希望能够帮助到一些初学者提升下架构程序时的思路。

1.URLManager

URLManager的架构最早出现Facebook的Three20框架中TTNavigator。是一个基于自定义URL协议安排ViewController的松耦合协议。

在传统ViewController中，从A push B, A与B之间的耦合性非常高，在多人协作时，每个人所写的VC(ViewController)将可能严重依赖别人的VC。而URLManager 中的VC切换时，A会向一个主解析器发送一个String 类似于 “app://B” ,这个自定义的协议告诉主解析器，需要push 出一个B，则主解析器会从A中Push出一个B，同时，还可以从String中解析出必要的参数传入B中。虽然，本质上仍然是从A push出B，但是因为总解析器作为一个中介者的存在, A与B的耦合性会大大降低。

 

2.VC传递对象的最佳方式

在上面说到，URLManager中参数的传递是从String中解析出来的。以前可能会出现VC 之间直接传递 对象或者UIImage 之类的情况，但这种情况似乎不能在URLManager架构中出现。

VC之间传递的对象或者数据，一般可能是需要缓存下来的数据。所以在我所写的URLManager架构中，传递的一般只是一个对象的Key值，而具体的对象一般是通过Key到缓存或者专门的DataCenter中查找(并且这个值一定是会被找到)。

 

3.复杂的Model 而非ViewController

在iOS的MVC中，ViewController承担了太多的工作，很多情况下很多人会在ViewController里面处理View的逻辑以及Model的修改传递，甚至是网络请求以及Model数据的存储。太过臃肿的ViewController会导致各种逻辑上bug以及代码维护上的困难，同时带来的是协作上的灾难，所有的人只能依据VC来划分工作，是不是太Low了？

于此，Model应该更多承担数据本身的工作，个人觉得，所有的数据获取、缓存、存储乃至数据的网络请求都应该属于Model的范畴。对于VC来说，一个数据对象是否应该被缓存，可能只是一个Model的一个属性，isCache的设置，其他的事情都交给Model去处理吧，ViewController不要插手Model内部的事情，做好Model和View 之间的桥梁就可以了。

 

4.还是Model：合理的缓存，存储与请求

最完整的情况下，通过Key查找一个Model数据，首先应该是从缓存中查找，然后是从数据库/本地文件中查找，最后如果还是没有找到，只能根据这个Key从网络端获取了。同时，从网络端获取一个数据后应该存储一份到本地Disk以及缓存。为了提升效率，查找Model是一个先后逻辑很强的工作，除非特别复杂的查找，尽量使用同步的方式,(当然很多情况下 异步也是必要的)；而存储一个数据，因为多级查找的存在，不怕太严重的数据丢失，异步方式应该是首选。

另外说一句，在上一篇中介绍了NSCache，这实在是一个杀器，使用方便同时效率极高，使用这个做缓存最合适了