客户端（iOS）上的核心数据caching来自服务器的数据策略
我已经编写了许多与后端进行通信的iOS应用程序。 几乎每次，我都使用HTTPcaching来caching查询，并将响应数据（JSON）parsing到Objective-C对象中。 对于这个新项目，我想知道一个核心数据方法是否合理。
这是我的想法：
iOS客户端向服务器发出请求，并将对象从JSONparsing到CoreData模型。
每次我需要一个新的对象，而不是直接获取服务器，我parsingCoreData，看看我是否已经提出了这个请求。 如果该对象存在并且没有过期，则使用获取的对象。
但是，如果对象不存在或已经过期（这里将应用一些caching逻辑），我将从服务器获取对象并相应地更新CoreData。
我认为有这样的架构可以帮助以下几点：1.避免对后端不必要的查询2.允许全面支持脱机浏览（您仍然可以使用DataCore的RDBMS进行关系查询）
现在这是我的问题：
- 我知道这有点需要编写后端逻辑第二次（服务器+ CoreData），但这是矫枉过正？
- 我有估计的任何限制？
- 任何其他的想法？
首先，如果您是注册的iOS开发人员，您应该可以访问WWDC 2010会话。 其中一个会议涵盖了一些您正在谈论的内容：“会话117，build立服务器驱动的用户体验”。 你应该可以在iTunes上find它 。
REST / JSON / Core Data的一个巧妙组合就像一个魅力，如果你打算重用你的代码，它将是一个巨大的节省时间，但需要有关HTTP的知识（以及关于核心数据的知识，如果你想让你的应用程序运行良好和安全）。
所以关键是要了解REST和Core Data。
-
了解REST意味着了解HTTP方法（GET，POST，PUT，DELETE，… HEAD？）和响应代码（2xx，3xx，4xx，5xx）和Headers（Last-Modified，If-Modified-Since，Etag，。 ..）
-
了解核心数据意味着知道如何devise模型，build立关系，处理耗时的操作（删除，插入，更新）以及如何在后台进行操作，以便您的UI保持响应。 当然，如何在sqlite上进行本地查询（例如，用于预取id的，因此您可以更新对象，而不是在获得其服务器端对等项时创build新对象）。
如果你打算为你提到的任务实现一个可重用的API，你应该确保你了解REST和核心数据，因为那是你可能做的最多的编码。 （现有的API – networking层（或任何其他）的ASIHttpRequest和用于parsing的任何良好的JSON库（例如SBJSON ）都可以完成这项工作。
使这样一个API简单的关键是让你的服务器提供一个RESTful服务，并且你的实体持有所需的属性（dateCreated，dateLastModified等），这样你就可以创build请求（很容易用ASIHttpRequest完成，无论是GET，PUT， POST，DELETE）并添加适当的Http Headers，例如Conditional GET：If-Modified-Since。
如果你已经习惯了Core Data，并且可以处理JSON，并且可以很容易地执行HTTP Request和处理响应（同样，ASIHttpRequest在这里有很多帮助，但也有其他的，或者你可以坚持下一级的Apple NS-Classes你自己），那么你所需要的就是为你的请求设置正确的HTTP头，并适当地处理Http-Response-Codes（假设你的服务器是RESTful）。
如果您的主要目标是避免重新更新服务器端的Core-Data实体，请确保您的实体中具有“最后修改的”属性，并对服务器执行条件GET（设置“If-Modified-Since”Http-Header to your entities“last-modified”date。如果资源没有改变（假设服务器是REST-ful），服务器将回应状态代码304（Not-Modified）如果发生了变化，服务器会将“Last-Modified”Http-Header设置为最后一次更改的date，将会以Status-Code 200响应，并在主体中传递资源（例如JSON格式）。
所以，一如既往，答案就是你的问题一如既往可能“取决于”。 它主要取决于你想要放在可重用的全部核心数据/rest层中。
告诉你的数字：我花了6个月的时间（在我的业余时间，每周3-10小时的速度）有我想要的地方，老实说，我还在重构，重命名，让它处理特殊用例（取消请求，回滚等），并提供细粒度的callback（可达性，networking层，序列化，核心数据保存…）。 但它非常干净，精细和优化，并希望符合我的雇主的一般需求（一个在线市场的分类与多个iOS应用程序的地方）。 这段时间包括学习，testing，优化，debugging和不断改变我的API（首先添加function，然后改进它，然后从根本上简化它，并再次debugging）。
如果上市时间是您的首要任务，那么您最好采用简单而实用的方法：不要重复使用，只要记住学习内容，在下一个项目中重构，重复使用和修复代码。 最后，所有的经验总结可能会清楚地展示你的API如何工作以及它提供了什么。 如果你还不在，那就试着把它作为项目预算的一部分，然后试着重复使用尽可能多的稳定的第三方API。
不好意思，我觉得你正在进入像构build一个通用的API甚至框架的东西。 这些事情需要时间，知识，家务和长期的承诺，而且大部分时间，这是浪费时间，因为你从来没有完成它们。
如果您只是想处理特定的cachingscheme，以允许离线使用您的应用程序，并最大限度地减lessnetworkingstream量，那么您当然可以实现这些function。 只需在请求中设置if-modified-since标题，检查最后修改的标题或etags，并将这些信息保留在persistet实体中，以便在稍后的请求中重新提交此信息。 当然，我也build议使用相同的HTTP标头caching（持久）本地资源，如图像。
如果你有修改（以REST方式）服务器端服务的好处，那么你很好，只要你实现它（从经验来说，你可以节省多达3/4的networking/parsing代码如果服务行为良好（返回适当的HTTP状态代码，避免检查零，string数字转换，date，提供lookup-id而不是隐式string等等）。
如果你没有那么奢侈的话，那么这个服务至less是RESTful的（这对你有很大的帮助），或者你必须修正客户端的东西（这经常是一个痛苦）。
有一个解决scheme在那里，我不能尝试，因为我在我的项目太重要，重构我的应用程序的服务器caching方面，但它应该是有用的人仍然在寻找答案：
这正是我所做的，但是我所做的更抽象得多。 那里非常有见地的东西。 我希望它可以帮助别人！
我认为这是一个有效的方法。 我已经做了很多次了。 棘手的部分是当你需要处理同步：如果客户端和服务器可以同时改变的东西。 您几乎总是需要特定于应用程序的合并逻辑。
