核心数据：简单、静态的基于 UITableView 的 iPhone 应用程序的过度杀伤力？答案

【问题标题】：Core Data: Overkill for simple, static UITableView-based iPhone App?核心数据：简单、静态的基于 UITableView 的 iPhone 应用程序的过度杀伤力？
【发布时间】：2011-02-11 11:13:30
【问题描述】：

我有一个相当简单的 iPhone 应用程序，它由多个视图组成，其中包含一个单独的分组表视图。这些视图一起保存在导航控制器中，导航控制器分组在选项卡栏中。简单的东西。

我的表格视图只做列表文本（如“Dog”、“Cat”和“Weasel”），并且这些数据是从一组 plist 中提供的。或许值得一提的是，这些表是“静态的”，因为它们的数据是预先确定的，并且只会被开发人员（在这种情况下，moi）修改——如果是这样，确实很少修改。

不过，这种基本的方法已经达到了极限，我想我需要一些更相关的东西。过去我曾使用过一些 Core Data，但仅限于数据由用户输入确定的应用程序。

我有四个密切相关的问题：

Core Data 对于一个主要由一系列简单表格视图组成的应用程序来说是否过分了？
您是否建议使用 Core Data 来管理预先确定且极不可能更改的数据？
是否可以锁定 Core Data 以使其数据不能更改，从而放弃我作为开发人员处理托管对象上下文的编辑和保存的责任？
如何以我知道它可以使用的格式向 Core Data 提供我预先确定的数据？

谢谢大家。

【问题讨论】：

标签： iphone objective-c uitableview core-data

【解决方案1】：

您可以考虑直接使用 SQLite API，而不是 Core Data，因为这样预填充数据库可能更容易。您可以在任何平台（Mac、Windows、Linux）上创建和修改 SQLite 数据库，然后将其作为资源复制到应用程序的包中。

您可以找到通过从应用程序包中复制 SQLite 数据库来创建用户数据库的教程/示例。在您的情况下，您可以只使用捆绑包中的那个。请务必以只读方式打开它。

【讨论】：

由于您已经在使用 OS X 来编写 iPhone 应用程序，因此预填充参数是有缺陷的。编写一个 Core Data 桌面应用程序进行预填充非常简单。 SQLite 太复杂了，无法证明在 NNW 以外的任何情况下都可以在 Core Data 上使用它
取决于数据的来源。并非所有数据都在 OS X 机器上开始其生命周期。
我不同意编写一个 Mac OS X Core Data 桌面应用程序来管理他的数据“非常简单”，尤其是当我们不知道这些数据是什么样子的时候。通过 Perl 或 Python 脚本填充数据库可能更容易，在这种情况下 SQLite 可能更容易。在不确切知道问题在做什么的情况下，我看不出有人可以声称 Core Data 绝对是一个优越的解决方案。

【解决方案2】：

你应该阅读why NetNewsWire switched

该帖子的两个主要内容：

我敢打赌，Core Data 在 95% 的情况下都是正确的选择。或者更多。它很容易使用。它很快（在大多数情况下）。

还有：

（规则：始终以最高级别工作。）

【讨论】：

【解决方案3】：

我建议坚持使用 plist，因为您的数据很少会更改，而且当它发生更改时，它将由开发人员驱动。

Core Data 非常强大，但您需要设置适量的管道和基础架构才能使其正常工作。
Core Data 将其 store 放置在您的 app bundle 之外（因为它必须在 iPhone 上运行），因此所有新安装都需要在第一次运行时将数据加载到 store 中。无论如何，这些数据可能必须存储为资源 plist，因此您不会为自己省去生成这些 plist 的麻烦。事实证明这不是真的，您可以存储持久存储的只读部分在 App bundle 中。

由于我也不确切知道您正在运行什么样的限制，Core Data 可能是解决方案，但我猜它不会。如果对象关系是您处理的最大困难，您应该阅读object archiving 作为一种将整个对象树存储在可以轻松保存为捆绑包中的资源并在必要时重新创建的形式的方法。

【讨论】：

Core Data 可以使用位于应用程序包内的只读数据。它甚至可以在应用程序包中将其存储的一部分设置为只读，将文档目录中的另一部分存储为读写。没有理由在 Core Data 上使用对象归档。
我删除了第 2 点，但第 1 点仍然有效。对archiveRootObject:toFile:、unarchiveObjectWithFile: 进行几次调用将比设置模型、托管对象、持久存储等简单得多。不过，您在回答中提出的要点可能会胜过我的第一个原因。你赢了这一轮，扎拉。

【解决方案4】：

答案很简单。如果您不需要坚持使用过时的格式（如 MSWord 等），那么您应该使用 Core Data。原始 SQLite 令人头疼，99.999% 的时间都不值得付出努力。

Core Data 比 plist 更高效，并且在项目不断发展时提供更大的灵活性。

使用 OS X 机器预填充 Core Data sqlite 文件也很容易；你知道，你最初用来开发应用程序的机器:)

NNW 的用例是这条规则的一个例外，如果我是一名赌徒，我敢打赌会引起 Core Data 团队的注意，并将在未来的更新中更正。顺便说一句，如果您使用 Core Data，您将免费获得更新。

【讨论】：

我不明白 iPhone 开发人员怎么能说 SQLite 很难使用，因为他们在通过手动引用计数管理内存时不眨眼。 SQLite 对于任何熟悉关系数据库的人来说都非常简单。 Core Data 也很简单，但不一定是所有数据存储和访问的最佳解决方案。
我有点希望有人会挥动 Core Data 的旗帜，尤其令人鼓舞的是你让这一切看起来如此简单，所以我想我会走这条路。我会将其标记为已接受的答案，但也很高兴知道 plist 或直接 SQLite 都是完全可行的解决方案，因此感谢您的所有回复。

【解决方案5】：

我建议使用普通的 SQLite。它更简单，更易于维护，您可以使用许多流行的 GUI 编辑器在非 mac 系统上构建数据库。对我来说，使用 Core data 仍然很痛苦。从静态 SQlite 数据库中填充表格视图的代码简单、直接且透明，而 Core Data 需要更多样板代码，一开始您甚至无法完全理解，而且总体上隐藏着很多您并不真正需要的复杂性.

【讨论】：