Core Data with Web Services 推荐模式？

Question

我正在为 iOS 编写一个应用程序，它使用 Web 服务提供的数据。我将核心数据用于本地存储和数据的持久性，以便在无法访问网络时用户可以使用一些核心数据集。

在构建这个应用程序时，我阅读了很多关于核心数据的帖子。虽然似乎有很多关于这样做的机制，但我在一般原则/模式上看到的较少。

我想知道是否有一些关于推荐交互模型的好的参考资料。

例如，用户将能够在应用程序上创建新对象。假设用户创建了一个新的员工对象，用户通常会创建它、更新它然后保存它。我已经看到将这些步骤中的每一个更新到服务器的建议-> 当用户创建它时，当用户对字段进行更改时。如果用户最后取消，则将删除发送到服务器。针对同一操作的另一个不同建议是将所有内容保存在本地，并且仅在用户保存时将完整的更新发送到服务器。

除了这个例子，我很好奇是否有一些关于如何处理 CRUD 操作并确保它们在网络服务器和 coredata 之间同步的一般建议/模式。

非常感谢。

Answer 1

我认为在您提到的情况下，最好的方法是仅在本地存储数据，直到用户提交添加新记录为止。将每个字段编辑发送到服务器有点过分。

iPhone 应用程序的一个通用习惯是没有“保存”之类的东西。用户通常会期望事情会在某个合理的时间提交，但它并不会作为保存本身呈现给用户。

因此，例如，假设您有一个 UI，允许用户编辑某种记录，这些记录将保存到本地核心数据并发送到服务器。在用户退出 UI 以创建新记录时，他们可能会点击一个名为“完成”的按钮（注意通常不称为“保存”）。当他们点击“完成”时，您需要启动核心数据写入并开始推送到远程服务器。服务器推送不一定会占用 UI 或让他们等到它完成 - 允许他们继续使用应用程序更好 - 但它正在发生。如果更新推送到服务器失败，您可能需要向用户发出信号或做一些适当的事情。

在规划写入核心数据和/或远程服务器的粒度时，一个很好的问题是：如果应用程序在应用程序的任何特定位置崩溃或手机没电会发生什么?可能发生多少数据丢失？好的应用程序可以降低数据丢失的风险，并且无论出于何种原因退出后，它们都可以以与之前非常相似的状态重新启动。

Answer 2

准备好扯掉你的头发。我一直在研究这个，问题是核心数据样本非常简单。当您转移到复杂模型并尝试使用 NSFetchedResultsController 及其委托时，您会遇到使用多个上下文的各种问题。

我使用一个在后台“块”中填充来自您的 Web 服务的数据，第二个用于 tableview 使用 - 您很可能最终使用 tableview 作为主列表和详细视图。

如果您希望在向/从服务器接收或发送数据时保持应用响应，请复习在 Cocoa 中使用块。

Answer 3

您可能想了解“事务” - 它基本上是将多个操作/更改组合为单个原子操作/更改。这有助于避免可能导致服务器上数据不一致的部分保存。

归根结底，这是一个非常大的话题——尤其是在服务器数据在多个客户端之间共享的情况下。最简单的情况是，您需要决定基本政策。最后一次保存会赢吗？服务器数据存储中的对象是否存在远程锁定的概念？例如，当两个客户端编辑同一对象的同一属性时，如何解决冲突？

关于如何在 iPhone 上完成事情，我同意 oculus 的观点，即“完成”为持久更改服务器提供了一个自然点（在单独的线程中）。