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

问题描述

我们有许多应用程序，我们以JSON的形式从远程Web服务获取数据，然后使用解析器将其转换为Core-Data模型。

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.

For one of our apps, I'm thinking we should do something different.

这个应用程式包含只读资料 ，这是易变，因此未本地缓存很长。 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个实体的核心数据模型，然后使用映射器将JSON导入其中。它看起来像这样的歌曲和舞蹈。我想我只想要坚持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. 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或其他过程DB非常擅长处理大量的低复杂度信息。如果数据很简单，那么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）随着数据增长，更复杂的核心数据迅速变得优越。 管理对象的管理部分管理关系和行为的复杂性。使用集合或SQL，您可以手动管理复杂性，并且可以发现自己很快就陷入了僵局。事实上，我看到人们试图用SQL管理复杂的数据，最终写自己的微型核心数据堆栈。不用说，当你结合复杂性和波动性核心数据是更好的，因为它处理插入和删除的自动副作用。

(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变成一个噩梦，Core Data，NSFetchedResultsController和UITableViewController / delegates使它变得无足轻重。）

(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） 。核心数据经过高度优化，因此图形大小的增加不会像使用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，而不是核心数据，核心数据有很高的开销。它真的不。即使当核心数据不是获取数据进出持久性的最便宜的方式时，它与其他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.

在这种特殊情况下，我不能从描述中得知你是在case（2）还是case（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个实体创建一个Core
数据模型，而
然后使用mapper将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 gives you more options than might be apparent at first glance.

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