客户端(iOS)上的核心数据,用于缓存来自服务器策略的数据

Pie*_*ult 57 architecture core-data ios

我写了许多与后端通信的iOS应用程序.几乎每次,我都使用HTTP缓存来缓存查询并将响应数据(JSON)解析为Objective-C对象.对于这个新项目,我想知道核心数据方法是否有意义.

这就是我的想法:

iOS客户端向服务器发出请求,并将对象从JSON解析为CoreData模型.

每当我需要一个新对象,而不是直接获取服务器时,我解析CoreData以查看我是否已经发出了该请求.如果该对象存在且尚未过期,则使用获取的对象.

但是,如果对象不存在或已过期(这里将应用某些缓存逻辑),我将从服务器获取对象并相应地更新CoreData.

我认为拥有这样的架构可以帮助实现以下目标:1.避免对后端进行不必要的查询2.允许完全支持离线浏览(您仍然可以使用DataCore的RDBMS进行关系查询)

现在这是我对神的问题:

  1. 我知道这有点需要第二次编写后端逻辑(Server + CoreData),但这有点过分吗?
  2. 我估计的任何限制?
  3. 还有其他想法吗?

cod*_*ash 93

首先,如果您是已注册的iOS Dev,您应该可以访问WWDC 2010会话.其中一个会议涵盖了您所谈论的一些内容:"会话117,构建服务器驱动的用户体验".你应该可以在iTunes找到它.

REST/JSON/Core Data的智能组合就像魅力一样,如果您计划重用代码,可以节省大量时间,但需要有关HTTP的知识(以及有关Core Data的知识,如果您希望应用程序运行良好)并且安全).

所以关键是要了解REST和核心数据.

  • 了解REST意味着理解HTTP方法(GET,POST,PUT,DELETE,HEAD ...?)和响应代码(2XX,3XX,4XX,5XX)和头(上次修改,如果修改-因为,Etag的. ..)

  • 了解核心数据意味着了解如何设计模型,设置关系,处理耗时的操作(删除,插入,更新)以及如何在后台进行操作,以便您的UI保持响应.当然,如何在sqlite上本地查询(例如,用于预取id,以便在获得服务器端等效项后可以更新对象而不是创建新对象).

如果您计划为您提到的任务实现可重用的API,则应确保了解REST和核心数据,因为这可能是您编写代码最多的地方.(现有的API - ASIHttpRequest为网络层(或任何其他)和任何好的JSON LIB(如SBJSON解析将做的工作).

关键要做出这样的API简单的是让你的服务器提供一个RESTful服务,和你的实体持有所需的属性(dateCreated会,dateLastModified等),这样你就可以创建要求(与ASIHttpRequest轻松完成,无论是GET,PUT, POST,DELETE)并添加适当的Http-Headers,例如用于条件GET:If-Modified-Since.

如果你已经感到舒服核心数据,并能处理JSON,可以很容易做到的HTTP请求,并再次处理响应(,ASIHttpRequest有很大帮助,在这里,但也有其他人,或者你可以坚持到较低级别的苹果NS-类和做它自己),然后您需要的是为您的请求设置正确的HTTP标头,并适当地处理Http响应代码(假设您的服务器是RESTful).

如果您的主要目标是避免从服务器端等效项重新更新Core-Data实体,只需确保您的实体中有"last-modified"属性,并对服务器执行条件GET(设置"If-Modified-Since"Http-Header到您的实体"最后修改"日期.如果该资源没有改变,服务器将使用状态代码304(未修改)进行响应(假设服务器是REST-ful)如果更改,服务器将"Last-Modified"Http-Header设置为上次更改的日期,将响应Status-Code 200并在正文中传递资源(例如,以JSON格式).

因此,与往常一样,答案是你的问题总是可能"它取决于".这主要取决于您希望在可重复使用的所有核心数据/休息层中添加的内容.

告诉你数字:我花了6个月(在我的业余时间,以每周3-10小时的速度)拥有我想要它的地方,老实说我仍在重构,重命名,让它处理特殊用例(取消请求,回滚等)并提供细粒度的回调(可达性,网络层,序列化,核心数据保存......),. 但它非常干净,精心设计和优化,并且有望满足我的雇主的一般需求(在具有多个iOS应用程序的分类广告的在线市场).那段时间包括学习,测试,优化,调试和不断更改我的API(首先添加功能,然后改进它,然后从根本上简化它,并再次调试它).

如果您的首选时间是您的首要任务,那么您最好采用简单实用的方法:无需考虑可重用性,只需记住学习内容,并在下一个项目中进行重构,重复使用和修复代码.最后,所有经验的总和可能会清楚地表明您的API如何运作以及它提供的内容.如果你还没有,请尽量让它成为项目预算的一部分,并尝试重用那些稳定的3'rd-Party API.

对于长篇回复感到抱歉,我觉得你正在进入建立通用API甚至框架之类的东西.这些事情需要时间,知识,家务和长期承诺,而且大多数时候,它们是浪费时间,因为你永远不会完成它们.

如果您只想处理特定的缓存方案以允许离线使用您的应用并最大限度地减少网络流量,那么您当然可以实现这些功能.只需在请求中设置if-modified-since标头,检查最后修改的标头或etags,并在持久化实体中保持该信息的持久性,以便您可以在以后的请求中重新提交此信息.当然,我还建议使用相同的HTTP标头在本地缓存(持久)资源,如图像.

如果你可以很好地修改(以REST-ful方式)服务器端服务,那么你很好,只要你很好地实现它(根据经验,你可以节省多达3/4的网络/解析代码iOS端,如果服务行为良好(返回适当的HTTP状态代码,避免检查nil,字符串的数字转换,日期,提供lookup-id而不是隐式字符串等...).

如果你没有那么奢侈,那么这项服务至少是REST-ful(这有很大帮助),或者你必须解决客户端的问题(这通常很痛苦).


Pie*_*ult 5

有一个解决方案,我无法尝试,因为我在我的项目中太远了重构我的应用程序的服务器缓存方面但它应该对那些仍在寻找答案的人有用:

http://restkit.org/

它确实完成了我所做的事情,但它比我所做的更抽象.非常有见地的东西.我希望它对某人有所帮助!

  • RestKit将AFNetworking用于其网络层 (6认同)
  • 为了记录:在github上有另一个新的API:https://github.com/gowalla/AFNetworking.它不提供Core Data持久性(RestKit会这样做),但它是一个非常好的,基于块的API,用于与RESTful服务进行交互.它内置了对JSON-Parsing的支持(适用于iOS <5的快速JSONKit和从iOS 5开始的Apple自己的新JSON序列化程序.如果你想要简单的异步网络,但仍然可以完全控制Core Data持久性,这看起来非常像清洁解决方案 (5认同)

Chr*_*hof 5

我认为这是一种有效的方法.我做了很多次.棘手的部分是当你需要处理同步时:如果客户端和服务器都可以同时改变事物.您几乎总是需要特定于应用程序的合并逻辑.