从RestKit到纯AFNetworking 2.0的过渡
从RestKit到纯AFNetworking 2.0的过渡
提问于 2014-04-10 22:10:34
过去两年，我一直在使用RestKit，但最近我开始考虑从这些monolith框架过渡，因为它看起来真的太过分了。
以下是我向前迈进的优势：
- 非常需要使用NSURLSession来获取背景数据，而RestKit只有向AFNetworking 2.0过渡的实验分支。没有完成过渡的实际日期。(主要原因)
- 不需要网络库中的CoreData支持，也不需要功能齐全的脱机数据存储。
- 对于响应/请求描述符的新概念感到头疼，因为它们不支持路径模式中的不同参数(例如。访问令牌参数)，并且无法使用自定义描述符在一行中创建对象请求操作。在这里，我放松了对象管理器作为外观的功能。
I.在对象映射过程中对RestKit的最大损失。可以推荐您使用的显示自己灵活和稳定的独立库吗？
II. --令我遗憾的是，我不需要功能齐全的存储，但在某些地方，我仍然需要一些缓存支持。我听说NSURLCache在上一个操作系统发行版中很有用。你用过了吗，策略是什么？当网络连接关闭时，它是否返回缓存的API响应？
III.，有人面临同样的问题吗？你应用了什么解决方案？也许有人可以给一些关于架构的的建议，他或她在多个应用程序中使用纯AFNetworking？
回答 1
Stack Overflow用户
回答已采纳
发布于 2014-10-31 04:44:41
与其他发表评论的人一致，AFNetworking + 地幔是一种简单而有效的方法，可以与Restful进行交互，并替换您错过的RestKit对象映射过程。
响应缓存支持的需求在很大程度上取决于上下文。但是，对于我最近的功能需求，我发现缓存特定控制器屏幕的视图模型，并且只有缓存API返回的引用数据，才能使应用程序逻辑保持相对简单，同时给用户一些连续性。连接问题的简单错误通知可以用横切方式处理.
与此相关的体系结构的一个想法是确保应用程序所依赖的app根据应用程序的经验提供数据。这使您的应用程序能够专注于它擅长的事情(非常灵活的用户体验)，并将逻辑转移到API中更接近于API的依赖项(如数据)。这有一个进一步的好处，以减少聊天的应用程序。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/23000024
复制相关文章
相似问题
腾讯云开发者
