iphone - 为 iPhone 创建 JSON 存储

Question

我们有很多应用程序，我们从远程 Web 服务获取数据作为 JSON，然后使用解析器将其转换为核心数据模型。

对于我们的一个应用程序，我认为我们应该做一些不同的事情。

这个程序有只读数据 ，即 volatile 因此没有在本地缓存很长时间 . JSON 是 层次分明与 大量嵌套的“对象” .文档通常包含不超过 20 个顶级项目，但最多可达 100K。

我不认为我想创建一个包含 100 个实体的核心数据模型，然后使用映射器将 JSON 导入其中。好像是这样的歌舞。我想我只是想将 JSON 保存在某个容易的地方，并能够查询它。 MongoDB 会很好，如果它在 iPhone 上运行。

iPhone 上是否有支持查询的 JSON 文档存储？

或者，我可以使用一些 JSON 解析器将数据转换为某种持久的 NSDictionary 并使用谓词进行查询吗？

或者也许将 SQLite 用作在 JSON 结构上手动创建索引的 BLOB 存储？

或者，我应该停止提示，并使用 Core Data 吗？ :)

帮助表示赞赏。

Answer 1

在决定使用什么持久性时，重要的是要记住 Core Data 首先是一个对象图管理系统。它真正的功能是创建模型- View - Controller 设计模式应用程序的运行时模型层。持久化实际上是 Core Data 的次要功能，甚至是可选功能。

主要的建模/持久性问题是数据的大小和数据的复杂性。因此，每种持久性的相对优势和劣势将分解如下:

    _______________________________
    |               |              |
  2 |               |              |
    |  SQL          |  Core Data   | 4
s   |               |              |
i   |_______________ ______________|
z   |               |              |
e   |               |              |
  1 |  Collection   |  Core Data   | 3
    |  plist/xml    |              |
    |               |              |
    -------------------------------  
              Complexity--->       

我们可以向其中添加第三个出租人维度，即波动性，即数据更改的频率

(1) 如果数据的大小、复杂性和波动性较低，则使用集合，例如序列化自定义对象的 NSArray、NSDictionary、NSSet 将是最佳选择。集合必须完全读入内存，以限制它们的有效持久性大小。它们没有复杂性管理，所有更改都需要重写整个持久性文件。

(2) 如果规模很大但复杂度很低，那么 SQL 或其他数据库 API 可以提供优越的性能。例如。一个老式的图书馆索引卡系统。每张卡片都是相同的，卡片之间没有关系，卡片没有行为。 SQL 或其他过程数据库非常擅长处理大量低复杂度的信息。如果数据很简单，那么 SQL 甚至可以有效地处理高度易变的数据。如果 UI 同样简单，那么将 UI 集成到 iOS/MacOS 应用程序的面向对象设计中几乎没有开销。

(3) 随着数据变得越来越复杂，Core Data 迅速变得更加优秀。 “托管对象”的“托管”部分管理关系和行为的复杂性。使用集合或 SQL，您必须手动管理复杂性，并且很快就会发现自己被淹没了。事实上，我看到有人尝试使用 SQL 管理复杂数据，最终编写了自己的微型核心数据堆栈。不用说，当您将复杂性与波动性结合起来时，Core Data 会更好，因为它会自动处理插入和删除的副作用。

(接口(interface)的复杂性也是一个问题。SQL 可以处理一个大型的静态单一表，但是当您添加可以动态更改的表的层次结构时，SQL 变成了一场噩梦。Core Data、NSFetchedResultsController 和 UITableViewController/delegates 做到了琐碎的。)

(4) 高复杂度和高规模，Core Data 显然是最佳选择。 Core Data 经过高度优化，因此图形大小的增加不会像 SQL 那样使事情陷入困境。您还可以获得高度智能的缓存。

另外，不要将“我完全理解 SQL，但不理解 Core Data”与“Core Data 开销很大”混淆。它真的没有。即使 Core Data 不是将数据输入和输出持久性的最便宜的方式，但当您考虑开发速度和可靠性时，它与 API 的其余部分的集成通常会产生出色的结果。

在这种特殊情况下，我无法从描述中判断您属于情况 (2) 还是情况 (4)。这取决于数据的内部复杂性和 UI 的复杂性。你说:

I don't think I want to create a Core Data model with 100's of entities, and then use a mapper to import the JSON into it.

您是指这里的实际抽象实体还是只是托管对象？请记住，实体之于托管对象就像类之于实例。如果是前者，那么是的，Core Data 将在前面做很多工作，如果是后者，那就不会了。您可以仅使用两个或三个相关实体构建非常大的复杂图形。

还请记住，您可以使用配置将不同的实体放入不同的存储中，即使它们在运行时都共享一个上下文。这可以让您将临时信息放入一个存储中，像使用更持久的数据一样使用它，然后在完成后删除存储。

Core Data 为您提供了比乍一看更多的选项。