iOS 封装网络请求类
由 liuchendi 发布于 2014年04月18日 ｜ 更新于 2014年04月19日无人欣赏。
做了两个项目了，一直沿用之前有点脆弱的网络请求类，情况是这样子的。写好成功和失败的回调函数，然后在网络请求类里面把请求结果解析后回调到控制器。
上星期公司请来一位有工作经验的人士给我们上了一节课，然后我发现他们的网络请求封装类是这样子的，有个独立的URL类，Client类，还有一个专门的参数Param类，Client类里面封装好一些常用的请求get/post操作，回调的时候还用GCD处理一些数据，比如解析，数据缓存等（还有一些细节没有记下来。）
请问一下大伙，你们的请求类是怎么封装的，能否说一下你们的思路，我想改进一下自己的请求类，想听听大伙的意见，之前一直都没用缓存，网络图片的加载是用的SDWebImage，现在也了解到了有些数据需要自己写缓存，但是摸索未果，所以想请各位大大指点指点，提提意见，或者能否提供一些测试源码或者参考学习资料的，感激不尽！
在iOS下为什么还需要独立的URL类？草草两句没看出意义何在。其他语言的话也许是需要的，尤其C/C++。Client类倒是通常都有，根据自己的业务需求作为通用请求的简化入口，或者还是根据业务定义一些粗分类的接口，大概含义和用途应该和你提到的差不多；另外还有一个用途是用来封装第三方库的接口，避免直接把第三方库的通讯API引入业务层。
通讯层的封装其实就是解决：1）简化业务层所需要的接口，而不是每次用到都得反复得构造相关数据结构；有些业务的通讯是比较统一化的，那还可以直接针对性的封装一对一的接口；2）隐藏第三方库，底层通讯库完全自己做比较麻烦，通常都直接用第三方的，但是如果直接把第三方库暴露到业务层使用的话，耦合性太强，万一第三方库升级或者甚至更改不同的库，对业务层影响很大。
缓存不难，有些第三方库本身就直接支持，或者根据自己需要做个支持简单，一般客户端的缓存机制不需要太复杂（不就是在特定目录下存储文件嘛，用个key或者编码过的url作为文件名都行），自动定期清或者由用户收工清除都可以。很复杂的缓存机制就得看业务需求了，这个不好泛泛而谈。
从需求考虑就好. 不同人写出来的都不一样结构. 分的细估计有一些不会改动 而有一些支持扩展性修改. 稳定一部分功能是必然. 归根到底还是解决问题. 然后再能兼顾维护性 等等就好了.