粗略地在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,这实在是一个杀器,使用方便同时效率极高,使用这个做缓存最合适了。

最后 照惯例 放一个粗糙的DEMO : URLManagerDemo

 

粗略地在iOS中使用URLManager架构》上有2条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.