问在客户端(iOS)缓存来自服务器的数据的核心数据策略

EN

首先，如果你是一名注册的iOS开发者，你应该有权访问WWDC2010会话。其中一个会议涵盖了您正在讨论的内容：“会话117，构建服务器驱动的用户体验”。您应该能够find it on iTunes通。

如果您计划重用代码，则REST / JSON / Core数据的巧妙组合非常有用，可以节省大量时间，但需要具备HTTP知识(如果您希望应用程序运行良好且安全，还需要了解Core Data )。

所以关键是要理解REST和核心数据。

• 理解REST意味着理解HTTP方法(GET、POST、PUT、DELETE、...HEAD ?)响应代码(2xx，3xx，4xx，5xx)和头文件(Last-Modified，If-Modified- so，Etag，...)
• Understanding )核心数据意味着知道如何设计你的模型，建立关系，处理耗时的操作(删除，插入，更新)，以及如何让事情在后台发生，让你的UI保持响应。当然还有如何在sqlite上本地查询(例如，用于预取id，以便您可以在获得服务器端等效项后更新对象，而不是创建新对象。

如果您计划为您提到的任务实现一个可重用的API，那么您应该确保理解REST和核心数据，因为这可能是您进行最多编码的地方。(用于网络层(或任何其他)的现有API的- ASIHttpRequest )和任何好的JSON库(例如，SBJSON)进行解析就可以完成这项工作。

使这类应用编程接口变得简单的关键是让您的服务器提供RESTful服务，并让您的实体拥有所需的属性(dateCreated、dateLastModified等)。因此，您可以创建请求(使用ASIHttpRequest很容易完成，无论是GET、PUT、POST、DELETE)，并添加适当的Http-Header，例如条件GET: If-Modified- with。

如果您已经对核心数据感到满意，并且可以处理JSON，并且可以轻松地执行HTTP请求和处理响应(同样，ASIHttpRequest在这里提供了很多帮助，但还有其他一些，或者您可以坚持使用较低级别的Apple NS-Classes并自己完成)，那么您所需要的就是为您的请求设置正确的HTTP头，并适当地处理Http-Response-Codes (假设您的服务器是REST-ful)。

如果您的主要目标是避免从服务器端等效项重新更新核心数据实体，只需确保您的实体中具有"last-modified“属性，并执行一个有条件的GET到服务器(将”If -modified-side“Http-Header设置为您的实体的"last-modified”日期。如果资源没有改变(假设服务器是REST-ful)，服务器将响应状态码304 (未修改)。如果更改，服务器会将" last -Modified“Http-Header设置为最后一次更改的日期，并以状态代码200响应，并在正文中传递资源(例如，JSON格式)。

因此，一如既往，你的问题的答案可能总是“视情况而定”。这主要取决于您希望在可重用的do- It -all核心数据/rest层中放入什么内容。

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

如果上市时间是你的首要任务，那么你最好使用一种简单而实用的方法:别管可重用性，只需牢记所学，并在下一个项目中重构，在这里和那里重用和修复代码。最后，所有经验的总和可能会体现在对API如何工作以及它提供了什么的清晰愿景中。如果你还没有做到这一点，那就试着让它成为项目预算的一部分，并试着尽可能多地重用稳定的第三方API。

对于冗长的回复，我感到很抱歉，我觉得你正在着手构建一个通用的API甚至是框架。这些事情需要时间，知识，家务事和长期的承诺，大多数时候，它们都是浪费时间，因为你永远不会完成它们。

如果你只想处理特定的缓存场景，允许离线使用你的应用程序，并最小化网络流量，那么你当然可以只实现这些功能。只需在请求中设置if-modified- set标头，检查最后修改标头或etags，并将该信息持久保存在您的持久实体中，以便您可以在以后的请求中重新提交此信息。当然，我还建议使用相同的HTTP头在本地(持久地)缓存图像等资源。

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

如果你没有这种奢侈，那么要么服务至少是REST-ful (这很有帮助)，要么你必须在客户端解决问题(这通常是一件痛苦的事情)。

有一个解决方案我不能尝试，因为我的项目太远了，无法重构我的应用程序的服务器缓存方面，但对于仍在寻找答案的人来说，它应该很有用：

http://restkit.org/

它和我做的完全一样，但比我做的要抽象得多。非常有洞察力的东西。我希望这对某些人有帮助！

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