客户端 (iOS) 上的 Core Data 缓存来自服务器的数据策略

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

这是我的想法：

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

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

但是，如果该对象不存在或已过期（此处将应用一些缓存逻辑），我将从服务器获取该对象并相应地更新 CoreData。

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

现在我向各位大神提出一个问题：

1. 我知道这需要再次编写后端逻辑（服务器+ CoreData），但这是否矫枉过正？
2. 我有什么低估的限制吗？
3. 还有其他想法吗？

首先，如果您是注册的 iOS 开发人员，您应该有权参加 WWDC 2010 会议。其中一场会议涵盖了您正在谈论的一些内容：“会议 117，构建服务器驱动的用户体验”。你应该能够在 iTunes 上找到它 http://developer.apple.com/videos/wwdc/2010/.

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

所以关键是理解REST和Core Data。

• 理解REST http://en.wikipedia.org/wiki/Representational_State_Transfer意味着理解 HTTP 方法（GET、POST、PUT、DELETE、...HEAD？）和响应代码（2xx、3xx、4xx、5xx）和标头（Last-Modified、If-Modified-Since、Etag、... ）

• 了解核心数据意味着了解如何设计模型、设置关系、处理耗时的操作（删除、插入、更新），以及如何让事情在后台发生，以便您的 UI 保持响应。当然，还有如何在 sqlite 上本地查询（例如，预取 id，以便在获得服务器端等效项后可以更新对象而不是创建新对象）。

如果您计划为您提到的任务实现可重用的 API，您应该确保您了解 REST 和核心数据，因为这可能是您进行最多编码的地方。 （现有 API -ASIHttp请求 http://allseeing-i.com/ASIHTTPRequest/对于网络层（或任何其他层）和任何好的 JSON 库（例如SBJSON http://code.google.com/p/json-framework/）用于解析就可以完成这项工作。

使此类 API 变得简单的关键是让您的服务器提供 RESTful 服务，并且您的实体持有所需的属性（dateCreated、dateLastModified 等），以便您可以创建请求（使用 ASIHttpRequest 轻松完成，无论是 GET、PUT、 POST、DELETE）并添加适当的 Http-Headers，例如对于条件 GET：If-Modified-Since。

如果您已经熟悉 Core Data 并且可以处理 JSON，并且可以轻松执行 HTTP 请求和处理响应（同样，ASIHttpRequest 在这里有很大帮助，但还有其他方法，或者您可以坚持使用较低级别的 Apple NS 类并执行），那么您所需要的就是为您的请求设置正确的 HTTP 标头，并适当地处理 Http-Response-Codes（假设您的服务器是 REST-ful）。

如果您的主要目标是避免从服务器端等效项重新更新核心数据实体，只需确保您的实体中有“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 方 API。

抱歉回复太长，我觉得您正在着手构建通用 API 甚至框架之类的事情。这些事情需要时间、知识、家务和长期的承诺，而且大多数时候，它们都是浪费时间，因为你永远无法完成它们。

如果您只想处理特定的缓存场景以允许离线使用您的应用程序并最大限度地减少网络流量，那么您当然可以只实现这些功能。只需在请求中设置 if-modified-since 标头，检查上次修改的标头或 etag，并将该信息保留在持久实体中，以便您可以在以后的请求中重新提交该信息。当然，我还建议使用相同的 HTTP 标头在本地缓存（持久）资源，例如图像。

如果您有能力修改（以 REST-ful 方式）服务器端服务，那么您可以很好地实现它（根据经验，您可以节省多达 3/4 的网络/解析代码） iOS 端，如果服务表现良好（返回适当的 HTTP 状态代码、避免检查 nil、字符串、日期的数字转换、提供查找 ID 而不是隐式字符串等...）。

如果您没有这种奢侈，那么要么该服务至少是 REST 式的（这有很大帮助），要么您必须在客户端修复问题（这通常很痛苦）。