带有 Web 服务的核心数据推荐模式？
我正在为 iOS 编写一个应用程序，它使用 Web 服务提供的数据。我使用核心数据进行本地存储和数据持久化，以便在无法访问网络时用户可以使用某些核心数据集。
在构建这个应用程序的过程中，我阅读了很多有关核心数据的帖子。虽然似乎有很多关于这样做的机制，但我很少看到这方面的一般原则/模式。
我想知道是否有一些推荐的交互模型的好参考。
例如，用户将能够在应用程序上创建新对象。假设用户创建一个新的员工对象，用户通常会创建它，更新它，然后保存它。我已经看到了将每个步骤更新到服务器的建议 -->当用户创建它时，当用户对字段进行更改时。如果用户最后取消，则会将删除发送到服务器。对于同一操作的另一个不同建议是将所有内容保留在本地，并且仅在用户保存时将完整更新发送到服务器。
除了这个例子之外，我很好奇是否有一些关于如何处理 CRUD 操作并确保它们在网络服务器和 coredata 之间同步的一般建议/模式。
非常感谢。
I am writing an app for iOS that uses data provided by a web service. I am using core data for local storage and persistence of the data, so that some core set of the data is available to the user if the web is not reachable.
In building this app, I've been reading lots of posts about core data. While there seems to be lots out there on the mechanics of doing this, I've seen less on the general principles/patterns for this.
I am wondering if there are some good references out there for a recommended interaction model.
For example, the user will be able to create new objects on the app. Lets say the user creates a new employee object, the user will typically create it, update it and then save it. I've seen recommendations that updates each of these steps to the server --> when the user creates it, when the user makes changes to the fields. And if the user cancels at the end, a delete is sent to the server. Another different recommendation for the same operation is to keep everything locally, and only send the complete update to the server when the user saves.
This example aside, I am curious if there are some general recommendations/patterns on how to handle CRUD operations and ensure they are sync'd between the webserver and coredata.
Thanks much.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为在您提到的情况下，最好的方法是仅在本地存储数据，直到用户提交添加新记录为止。将每个字段编辑发送到服务器有点过多。
iPhone 应用程序的一个普遍习惯是没有“保存”这样的东西。用户通常会期望在某个合理的点提交一些事情，但它本身并不作为保存呈现给用户。
例如，假设您有一个 UI，允许用户编辑某种记录，该记录将保存到本地核心数据并发送到服务器。当用户退出用于创建新记录的 UI 时，他们可能会点击名为“完成”的按钮（注意通常不称为“保存”）。当他们点击“完成”时，您将需要启动核心数据写入并开始推送到远程服务器。服务器推送不一定会占用用户界面或让他们等待直到它完成——允许他们继续使用应用程序更好——但它正在发生。如果更新推送到服务器失败，您可能需要向用户发出信号或执行适当的操作。
在规划写入核心数据和/或远程服务器的粒度时，要问自己一个好问题：如果应用程序在应用程序中的任何特定位置崩溃或手机没电，会发生什么？可能会发生多少数据丢失？好的应用程序可以降低数据丢失的风险，并且可以在因任何原因退出后以与之前非常相似的状态重新启动。
I think the best approach in the case you mention is to store data only locally until the point the user commits the adding of the new record. Sending every field edit to the server is somewhat excessive.
A general idiom of iPhone apps is that there isn't such a thing as "Save". The user generally will expect things to be committed at some sensible point, but it isn't presented to the user as saving per se.
So, for example, imagine you have a UI that lets the user edit some sort of record that will be saved to local core data and also be sent to the server. At the point the user exits the UI for creating a new record, they will perhaps hit a button called "Done" (N.B. not usually called "Save"). At the point they hit "Done", you'll want to kick off a core data write and also start a push to the remote server. The server pus h won't necessarily hog the UI or make them wait till it completes -- it's nicer to allow them to continue using the app -- but it is happening. If the update push to server failed, you might want to signal it to the user or do something appropriate.
A good question to ask yourself when planning the granularity of writes to core data and/or a remote server is: what would happen if the app crashed out, or the phone ran out of power, at any particular spots in the app? How much loss of data could possibly occur? Good apps lower the risk of data loss and can re-launch in a very similar state to what they were previously in after being exited for whatever reason.
准备好把你的头发扯掉很多。我一直在研究这个问题，问题是核心数据示例非常简单。当您转向复杂模型并尝试使用 NSFetchedResultsController 及其委托时，您会遇到使用多个上下文的各种问题。
我使用一个在后台“块”中填充来自 Web 服务的数据，第二个用于要使用的表格视图 - 您很可能最终会使用表格视图作为主列表和详细视图。
如果您希望应用程序在从服务器接收或发送数据时保持响应，请复习一下 Cocoa 中块的使用。
Be prepared to tear your hair out quite a bit. I've been working on this, and the problem is that the Core Data samples are quite simple. The minute you move to a complex model and you try to use the NSFetchedResultsController and its delegate, you bump into all sorts of problems with using multiple contexts.
I use one to populate data from your webservice in a background "block", and a second for the tableview to use - you'll most likely end up using a tableview for a master list and a detail view.
Brush up on using blocks in Cocoa if you want to keep your app responsive whilst receiving or sending data to/from a server.
您可能想阅读有关“事务”的内容 - 这基本上是将多个操作/更改分组为单个原子操作/更改。这有助于避免部分保存可能导致服务器上的数据不一致。
最终，这是一个非常大的主题 - 特别是如果服务器数据在多个客户端之间共享。最简单的是，您需要决定基本政策。最后保存获胜吗？服务器数据存储中的对象是否存在远程锁定的概念？例如，当两个客户端编辑同一对象的同一属性时，如何解决冲突？
关于 iPhone 上的操作方式，我同意 oculus 的观点，即“完成”为持久更改服务器提供了一个自然点（在单独的线程中）。
You might want to read about 'transactions' - which is basically the grouping of multiple actions/changes as a single atomic action/change. This helps avoid partial saves that might result in inconsistent data on server.
Ultimately, this is a very big topic - especially if server data is shared across multiple clients. At the simplest, you would want to decide on basic policies. Does last save win? Is there some notion of remotely held locks on objects in server data store? How is conflict resolved, when two clients are, say, editing the same property of the same object?
With respect to how things are done on the iPhone, I would agree with occulus that "Done" provides a natural point for persisting changes to server (in a separate thread).