使用自定义核心数据持久存储通过 Web 服务获取数据？

Posted 2023-03-04

【中文标题】使用自定义核心数据持久存储通过 Web 服务获取数据？

【英文标题】：use custom core data persistent store for getting data via webservices?

【发布时间】：2010-08-06 01:17:15

【问题描述】：

这是个好主意吗？什么时候是好主意，什么时候是坏主意？

刚刚在一个 WWDC 视频中听说过这一点，我不太明白为什么要这样做。看起来很复杂，我看不到好处。

【问题讨论】：

能否请您发布 WWDC 视频的名称/年份？

WWDC 2010 会议 117 @ 35:53

【参考方案1】：

在我看来，这将是完全抽象数据访问层。然后，您就可以使用 Core Data 获取请求 API 访问 Web 服务。您还可以在不影响应用程序逻辑的情况下在持久存储中实现缓存。

此外，更改 Web 服务请求/响应格式可能只会影响持久存储层。

我认为这对大型请求很有好处。由于网络在电池寿命方面非常昂贵，因此应用程序应使用尽可能少的带宽，因此在我看来，开发一个发送更多信息但使用 Core Data 一次仅访问子集的单个请求是一个不错的设计。

最后，我认为 Core Data API 可以很好地与主要的 ORM Web 框架（例如 rails 或 django）融合。

【讨论】：

你不认为Core Data 通过网络传输数据是多余的吗？你能看出潜在的性能问题吗？如何优雅地处理网络断开连接？我没有深入研究 API，但我真的很想知道它带来的好处与增加的复杂性（参见视频，子类化持久存储......：S）

也许是矫枉过正。但是，如果这意味着除了使用 Core Data 之外我永远不必访问我的数据，因为所有 Web 服务都包含在持久存储中，并且我可以通过在本地持久保存并在网络透明恢复时更新来管理断开连接，这可能是值得的。在我正在开发的应用程序中，我不这样做，只是使用旧方法并在外部实现 Web 服务的缓存和更新，但我可能会考虑在下一个应用程序中使用它。

【参考方案2】：

它很复杂，它旨在展示 你可以用 Core Data 做什么。我个人喜欢将服务器通信与本地缓存分开，然后根据本地缓存的更改更新服务器。这意味着我使用的代码会监听来自 Core Data 的保存事件，然后更新服务器。