在iPhone应用程序中使用核心数据有什么价值吗？

人们能举例说明为什么他们会在应用程序中使用coreData吗

我这样问是因为大多数应用程序只是中央服务器的客户端，在中央服务器上，某种API会为您提供所需的信息

在我的例子中，我正在为一个具有API的web应用程序编写时间表应用程序，我正在讨论在核心数据（Sqlite）中复制服务器上的数据结构是否有价值

e、 g

这个项目有很多时间表 这个雇员有很多时间表

例如，在我看来，每次调用项目列表或现有时间表时，我都可以连接到API

我意识到，在某种离线模式下，您可以在本地存储核心数据，但这会带来更多问题，因为您现在在重新连接时将数据同步回web服务器时遇到了一个大问题。。e、 g.为时间表选择的项目不再存在

任何有经验的开发人员都能说明什么时候核心数据是最佳实践方法的经验吗

编辑

---

我当然意识到存储本地持久性是有价值的，但用户默认值的关键价值似乎涵盖了我所能想到的大多数应用程序。

如果您想在手机上本地存储数据，它是理想的选择

不过说真的，如果你觉得你的时间表应用程序不需要它，那就不要担心它，也不要使用它

---

解决“脱机”模式下的同步问题将在应用程序设计中详细说明。例如-不允许删除项目。你为什么要这么做？您不想回到过去，查看特定项目的以前数据吗？取而代之的是，在项目上有一个标记，将其显示为非活动状态，以及将其设置为非活动状态的日期/时间。如果从设备同步的数据是针对该项目的，并且在标记为非活动的日期/时间之前，则可以进行同步。否则，将显示一条消息，用户将不得不对其进行排序。

如果是真正的问题或web服务周围的瘦GUI客户端，则是否需要在本地存储某些数据完全取决于应用程序的设计。除了“脱机”模式之外，在客户端缓存服务器数据的另一个原因可能是为了从服务器上获取流量负载。试想一下，服务器每次将整个时间表数据发送到客户端，或者仅发送更改，这意味着什么。是的，这意味着双方都需要更多的实施，但在某些情况下，它有着巨大的优势

编辑：添加示例

---

在时间表应用程序中，每个用户有1000条记录，其中一条记录是cca 1 KB。在这种情况下，每次用户启动您的应用程序时，它都必须从您的服务器获取~1M字节的数据。如果您在本地缓存数据，服务器会告诉您自上次更新以来有两条记录被更新，因此您只需下载2kbyte。现在，您应该将其扩展到数万用户，您将立即注意到服务器带宽和CPU使用率的差异。

您不应该将CoreData简单地看作一个SQLite数据库。它不仅仅是一个SQLite数据库。当然，SQLite是一个选项，但也有其他选项，比如内存中，以及截至iOS5的大量自定义数据存储。显然，CoreData的最大好处是持久性。但是，即使您使用的是内存中的数据存储，您也可以从结构良好的对象图中获得好处，而且从数据存储中提取信息或将信息放入数据存储中的所有繁重工作都由CoreData为您处理，而您无需担心数据存储背后的支持内容。当然，今天您不太关心持久性，所以可以使用内存中的数据存储。如果明天，或者一个月后，或者一年后，您决定添加一个真正从持久性中受益的特性，会发生什么？使用CoreData，您只需更改或添加一个持久数据存储，所有获取信息的方法都保持不变。与直接访问SQLite或其他数据存储相比，这种添加的开销是最小的。这就是最大的好处：抽象。本质上，抽象是OOP背后最强大的东西之一。诚然，构建仅用于内存存储的数据模型对于你的应用来说可能是过度的，这取决于应用的参与程度。但是，正如一个旁注，你可能想考虑什么是更快：从你的Web服务请求信息每次你要执行一些动作，或请求一次信息，将其存储在内存中，并在该剩余的会话中作用于该存储值。内存中的数据存储不会持久化到该特定会话之外

---

此外，使用CoreData，您还可以获得许多其他出色的功能，如保存、获取和撤消重做。

基本上有两种应用程序。为您提供本地功能（游戏、专业应用程序、导航系统等）和允许访问远程服务的功能

你的应用程序似乎属于第二类。如果您访问远程服务，您的用户将希望访问新的或实时数据（您不想阅读2周前的Facebook帖子），但在某些情况下，本地缓存是有意义的（例如，当您在网络不稳定的火车上阅读邮件）

我假设，与访问实时数据的重要性相比，在未连接到网络的情况下访问缓存条目对您的客户（内部或外部）的价值非常低。因此，本地存储可能根本没有必要

如果时间表中没有数百个条目，“正常”序列化（NSCoding协议）可能就足够了。如果您只访问一些“仪表板数据”，您将能够处理简单的请求/响应缓存（NSURLCache可以做很多事情）