我正在构建一个 iOS 客户端应用程序以与现有后端架构交互。为了减少延迟、API 调用和有效负载，最好在客户端“缓存”模型数据以加快索引速度，然后根据需要相应地对客户端/服务器端进行更新。

当前的理论堆栈看起来像这样:

Server Side >>>>>>>>>>>>>>>>> Client Side
-----------------------------------------
PHP >> JSON >> CORE DATA >> UIKit Objects

注意: 还值得注意的是，iOS 客户端虽然本身在内部遵循 MVC，但本质上是更大的 MVC 客户端-服务器架构中的“ View ”。因此，就像在用户操作后更新模型或在模型更改后更新 View 一样，服务器需要与客户端更改同步，而客户端需要与服务器端更改同步。

一些上下文:

一个。许多不同的数据结构可能会通过管道传输，并且必须动态构建到 UIViews 中。可能必须定义模式(除了记住可接受的对象结构是什么之外，我不确定是否有“最佳方式”来在客户端遵守 JSON 模式)。我已经意识到需要将与创建自定义 View (“ View ”模型)相关的模型数据与将在这些 View 中呈现的内容(“常规”模型)的模型数据分开。

B.最终用户应该能够立即CRUD(创建、读取、更新、销毁)这些 View 中显示的大部分数据(但不能对 View 本身进行 CRUD)。他们稍后可能需要在 Web 界面或其他上下文中查看此内容。

C. RestKit 看起来很适合从 API 到 JSON 再到 COREDATA。当需要将客户端模型副本推送到服务器时，我需要了解它是否在结构上支持回调。也许最好的方法是在发生更改时在客户端模型中记录下来，并通知任何基于 RestKit 的 HTTP 管理器将其传递给服务器。

终极问题: 谁能谈谈这种架构的最佳实践、陷阱、技巧和框架？ (特别是在性能和​​客户端与服务器之间的工作分配方面，但也非常感谢一般性建议。)

最佳答案

我已经解决了这个问题，希望我能提供一些见解。

关于 A) 是的，如果您打算使用 CoreData(或 RestKit)，您需要预先了解您的架构。否则你将无法映射动态对象，除非你有一些通用的对象类型，你只是在其中存储 JSON 字符串或其他东西，但这听起来不像你想做的，因为你提到用户编辑那些对象。

B) RestKit 会为您处理推送到服务器的操作，但我想您仍然需要对此进行一些控制。我们通过始终先在本地保存然后在成功保存后推送到服务器来处理它。这也使我们能够在没有网络的情况下工作。您只需要处理当服务器拒绝您的用户正在执行的更新/创建/删除时发生的情况。

C) RestKit 可能会帮助您完成 80% 的工作，就像它对我们所做的那样。只要了解 REST 端点和对象映射，以及抽象 HTTP 请求，就会有很大的帮助。就系统理解变化而言，我们在托管对象上保留了一个标志，表明该对象是否需要同步。我们可以根据这些标志进行获取并将服务器向上推送。

RestKit 的一件事是您可以在您的 CoreData 模型中拥有其他属性，这些属性不一定是 JSON 模式的一部分，但您可能需要在您的应用程序中使用。例如，我已经提到了用于了解对象是否需要同步的标志。我们还保留了用于搜索的预计算字段和一些其他随机信息，用于确定要推送到服务器的对象的顺序(依赖项)。

希望这对您有所帮助。如果您有更具体的问题，我可能会有更多答案。

关于iphone - iOS 客户端 : "Caching" Server-side data to persistent storage，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9058112/