为 iPhone 创建 JSON 存储 [英] Creating a JSON Store For iPhone

问题描述

我们有大量的应用程序，我们从远程网络服务获取数据作为 JSON，然后使用解析器将其转换为核心数据模型.

We have loads of apps where we fetch data from remote web services as JSON and then use a parser to translate that into a Core-Data model.

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

此应用具有只读数据，该数据易变，因此不会在本地缓存很长时间.JSON 具有深度分层，具有大量嵌套对象".文档通常包含不超过 20 个顶级项目，但最多可以包含 100K.

This app has read-only data, which is volatile and therefore not cached locally for very long. The JSON is deeply hierarchal with tons of nested "objects". Documents usually contain no more than 20 top level items, but could be up to 100K.

我不认为我想创建一个包含 100 个实体的 Core Data 模型，然后使用映射器将 JSON 导入其中.好像是这样的歌舞.我想我只是想将 JSON 保存在某个容易的地方，并且能够查询它.如果 MongoDB 在 iPhone 上运行，那就没问题了.

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. It's seems like such a song and dance. I think I just want to persist the JSON somewhere easy, and have the ability to query it. MongoDB would be fine, if it ran on iPhone.

iPhone 上有支持查询的 JSON 文档存储吗?

Is there a JSON document store on the iPhone that supports querying?

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

Or, can I use some JSON parser to convert the data to some kind of persistent NSDictionary and query that using predicates?

或者使用 SQLite 作为 BLOB 存储，在 JSON 结构上手动创建索引?

Or perhaps use SQLite as a BLOB store with manually created indexes on the JSON structures?

或者，我应该停止抱怨，并使用 Core Data 吗?:)

Or, should I stop whining, and use Core Data? :)

感谢帮助.

推荐答案

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

When deciding what persistence to use, it's important to remember that Core Data is first and foremost an object graph management system. It true function is to create the runtime model layer of Model-View-Controller design patterned apps. Persistence is actually a secondary and even optional function of Core Data.

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

The major modeling/persistence concerns are the size of the data and the complexity of the data. So, the relative strengths and weaknesses of each type of persistence would break down like this:

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

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

To which we could add a third lessor dimension, volatility i.e. how often the data changes

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

(1) If the size, complexity and volatility of the data are low, then using a collection e.g. NSArray, NSDictionary, NSSet of a serialized custom object would be the best option. Collections must be read entirely into memory so that limits their effective persistence size. They have no complexity management and all changes require rewriting the entire persistence file.

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

(2) If the size is very large but the complexity is low then SQL or other database API can give superior performance. E.g. an old fashion library index card system. Each card is identical, the cards have no relationships between themselves and the cards have no behaviors. SQL or other procedural DBs are very good at processing large amounts of low complexity information. If the data is simple, then SQL can handle even highly volatile data efficiently. If the UI is equally simple, then there is little overhead in integrating the UI into the object oriented design of an iOS/MacOS app.

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

(3) As the data grows more complex Core Data quickly becomes superior. The "managed" part of "managed objects" manages complexity in relationships and behaviors. With collections or SQL, you have manually manage complexity and can find yourself quickly swamped. In fact, I have seen people trying manage complex data with SQL who end up writing their own miniature Core Data stack. Needless to say, when you combine complexity with volatility Core Data is even better because it handles the side effects of insertions and deletion automatically.

(接口的复杂性也是一个问题.SQL 可以处理一个大型的静态单一表，但是当您添加可以动态更改的表层次结构时，SQL 就变成了一场噩梦.核心数据、NSFetchedResultsController 和 UITableViewController/代表使它变得微不足道.)

(Complexity of the interface is also a concern. SQL can handle a large, static singular table but when you add in hierarchies of tables in which can change on the fly, SQL becomes a nightmare. Core Data, NSFetchedResultsController and UITableViewController/delegates make it trivial.)

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

(4) With high complexity and high size, Core Data is clearly the superior choice. Core Data is highly optimized so that increase in graph size don't bog things down as much as they do with SQL. You also get highly intelligent caching.

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

Also, don't confuse, "I understand SQL thoroughly but not Core Data," with "Core Data has a high overhead." It really doesn't. Even when Core Data isn't the cheapest way to get data in and out of persistence, it's integration with the rest of the API usually produces superior results when you factor in speed of development and reliability.

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

In this particular case, I can't tell from the description whether you are in case (2) or case (4). It depends on the internal complexity of the data AND the complexity of the UI. You say:

我不认为我想创建一个核心具有 100 个实体的数据模型，以及然后使用映射器导入 JSON进入它.

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 将需要大量的前期工作，如果是后者，则不会.您可以仅使用两个或三个相关实体构建非常大的复杂图形.

Do you mean actual abstract entities here or just managed objects? Remember, entities are to managed objects what classes are to instances. If the former, then yes Core Data will be a lot of work up front, if the latter, then it won't be. You can build up very large complex graphs with just two or three related entities.

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

Remember also that you can use configuration to put different entities into different stores even if they all share a single context at runtime. This can let you put temporary info into one store, use it like more persistent data and then delete the store when you are done with it.

Core Data 为您提供了比乍看之下更多的选择.

Core Data gives you more options than might be apparent at first glance.

这篇关于为 iPhone 创建 JSON 存储的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！