ios之coredata(一)

下面开始学习一下CoreData。

Core Data不是一个关系型数据库，也不是关系型数据库管理系统(RDBMS)。
Core Data 为数据变更管理、对象存储、对象读取恢复的功能提供了支持。 它可以使用SQLite作为持久化存储的类型。 它本身并不是一个数据库（这点很重要，比如，你可以使用Core Data来记录数据变更，管理数据，但并不能用它向文件内存储数据）。

首先简单的介绍一下概念：

 

数据表 --–> Entity  （You usually define entities in a managed object model usingthe data modeling tool in Xcode）.

表格的记录 --> NSManagedObject （一个表记录就是一个NSManagedObject实例）

描述表格结构 --> NSEntityDescription

数据库中所有表格和他们的联系 -->NSManagedObjectModel

数据库存放方式 --> NSPersistentStoreCoordinator

数据库操作 --> NSManagedObjectContext

查询语句 --> NSFetchRequest

 

一、Core Data基础

 

1. Core Data基本架构

    在大部分程序中，你要能通过某种方式打开一个包含对象归档的文件， 这个文件内至少要有一个根对象的引用。另外，还得能将所有的对象归档到文件中，如果你想要实现撤销的功能，就还要记录对象的更改情况。例如，在 Employee的示例程序中，你要能打开一个包含有employee和department对象归档的文件，相应的，你还有可能将程序中的employee、department对象归档到文件中去。

Figure 1 按照Core Data文档结构管理的对象示意图

使用Core Data的框架，大多数的功能都可以自动实现，因为我们有managed object context（管理对象的上下文，有时直接叫"Context"）。managed object context就像是一个关卡，通过它可以访问框架底层的对象——这些对象的集合我们称之为"persistence stack"（数据持久栈）。 managed object context作为程序中对象和外部的数据存储的中转站。栈的底部是persistence object stores（持久化数据存储），请看Figure 2的示意图。

Figure 2 使用Core Data的文档管理示意图

 

2、被管理对象（Managed Object）和上下文(Managed Objects and Contexts)

    你可以把被管理对象上下文想象成一个”聪明“的便笺簿。当你从数据持久层获取对象时，就把这些临时的数据拷贝拿到写在自己的便笺簿上（当然，在便笺上对象会 “恢复”以前的对象图结构）。然后你就可以随心所欲的修改这些值了（本子是你的，随便画都可以），除非你保存这些数据变化，否则持久层的东西是不会变 的。（跟修改文件后要保存是一个道理）。

    附在Core Data框架中模型对象（Model objects）常被称为“被管理对象”(Managed objects)。所有的被管理对象都要通过上下文进行注册。使用上下文，你可以在对象图中添加、删除对象，并记录对象的更改（包括单个对象，或是对象间 的关系）。记录更改后就能支持撤销和重做的功能。同时，上下文还能保证关系更改后对象图的完整性。

    如果你想要保存所做的修改， 上下文会保证对象的有效性。在验证有效性后，更改会被写入到persistent store(持久化存储层)中。你在程序中的添加和删除动作都会被作用在存储的数据中。

    在你的一个程序中，可能存在多个上下文。 对于数据存储(store)中的每个对象，对应的都有唯一的一个被管理对象(managed object)和上下文相关联（详情请查看"Faulting and Uniquing"文档）。换个角度来想，在persistent store中存储的对象有可能被用在不同的上下文中，每个上下文都有与之对应的被管理对象，被管理对象可以被独立的修改，这样就可能在存储 时导致数据的不一致。Core Data提供了许多解决这个问题的途径（请查看"Using Managed Object"一章）。

3、获取数据的请求(Fetch Requests)

    要使用上下文来获取数据，你需要创建相应的请求(Fetch request)。 Fetch request对象包含你想获取的对象的描述。例如：“所有 Employee”，或“所有的Employee，department是marketing，按薪资降序排列”。Fetch Request包含三个部分。使用最简单的写法，必须指定实体（Entity）的名称，这就暗示了，每次只能获得一种类型的实体。 Fetch Request 还可以包含谓词（predicate）——注：有些地方也把这个叫断言，个人感觉谓词更准确些。谓词将描述对象需要满足的条件（这就和我们在SQL里加的 限定条件差不多，正如前面的"All Employees, in the Marketing department"）。另外，Fetch Request还可包含一个用于描述排序方式的对象（熟悉的Order by操作）。如图Figure3所示：

 

 

在程序中，你将Fetch Request这个请求发送给上下文，上下文就会从相关的数据源中查找复合条件的对象（也可能找不到），并返回。 所有的被管理对象（managed object）都必须在上下文中注册，因此通过fetch request获得的对象自动被注册。但如前所述，每个在持久存储层（persistence store）中的对象都对应一个和上下文相关的被管理对象(managed object)，因此，如果在上下文中已经存在了fetch request要取的对象，那么这个被管理对象将被返回。

 

4、持久化存储助理(Persistent Store Coordinator)

    之前提到过，程序中的对象和外部存储的数据通过Core Data框架中的一系列对象进行协调，这一系列的对象总的被称为持久存储栈(Persistence stack)。在栈顶是被管理对象上下文(Managed object context)，而栈底是持久化对象存储层(Persistence object store)。在它们之间就是持久化存储助理。如下图：

 

    事实上，持久化存储助理定义了一个栈。从设计方面考虑，它就是可以作为上下文的”外观“。持久化存储助理智能关联一个被管理对象的模型。如果你像要把不同的实体放到不同的存储中去，就需要为你 的模型实体做“分区”，方式是通过定义被管理对象模型的configurations。（请参考"Configurations"一章）。

    Figure 4演示了这样的一个结构：employees和departments存储在一个文件中，customers和companies存储在另外一个文件中。当你要获取对象的时候，它们从相关的文件中自动获取；当保存时，又被归档到相应的文件中。

 

5、持久化存储(Persistent Stores)

    持久化存储是和单独的一个文件或外部的数据关联的，它负责将数据和上下文中的对象进行对应。通常，需要你直接和持久化对象存储打交道的地方，就是指定新的、 和程序进行关联的外部数据的位置（例如，当用户打开或保存一个文档）。大多数需要访问持久化存储的动作都由上下文来完成。

    程序的代码—— 特别是和被管理对象相关的部分——不应该对持久化存储做任何假设（也就是不需要自己考虑存储的方式或过程）。 Core Data对几种文件格式有原生的支持。你可以选择一种自己程序需要的。假设在某个阶段你决定换一种文件的格式，而又不想修改程序的框架，而且，你的程序做了适当的抽象（注：这个就属于设计方面的东东了），这时，你就能尝到使用Core Data的甜头了。例如，在最初的设计中，程序只从本地文件中获取数据，而你的程序没有去硬指定对应数据的获取位置，而是可以在后期指定从远程位置添加新的数据类型，这样你就可以使用新的类型，而不需要修改代码。（这段还是感觉翻的不太合适）。

6、 被管理对象和被管理对象模型（Managed Objects and the Managed Object Model）

为了管理对象图，也为了提供对象持久化的功能，Core Data需要对对象有很强的描述能力。被管理对象模型就是程序中对象、实体描述的概要图，如图Figure 5所示。创建模型的常用做法是通过Xcode的图形化建模工具Date Model Design tool。但是如果你愿意的话，也可以在运行时通过代码来建模。

Figure 5 有两个实体的对象模型

 

模型由多个实体描述对象Entity Description构成，每个描述提供实体的某项元数据，它们包含实体名、实体在程序中的类名（当然，类名和实体名不需要一致）、属性还有关系。属性和关系依次被属性和关系描述对象所代表，如图Figure 6所示。

Figure 6 带有两个属性和一个关系的的实体描述

 

 

被管理对象必须是NSManagedObject或其子类的实例。 NSManagedObject可用来表示任何实体。它使用内部私有的存储机制来维护自身的属性，并执行一个被管理对象所必须的基本操作。一个被管理对象拥有一份实体描述的引用。在使用时，它通过实体描述来找到自身的元数据，包括实体名和属性、关系的信息。你也可以继承NSManagedObject来执 行额外的操作。

 

被管理对象模型（Managed Object Models）

    多数Core Data的功能依赖于你创建的，用来描述程序的实体及其属性、关系的模型图。 模型图由NSManagedObjectModel所表示。一般说来，模型的信息越充实，Core Data能提供的功能就越好。 

 

被管理对象模型的特性

    被管理对象模型是 NSManagedObjectModel的实例。它描述了你在程序中使用的实体的概要信息。

 

7、实体（Entities）

Entity代表对象-关系映射的架构,由此可以生成一个对象类,并对应持久存储中的一个数据表(ORM关系即可建立)。通常是在Xcode 可视化环境下创建 Entity,也可用代码创建(NSEntityDescription 对象)

实体由属性（property）组成，属性分成3种类型，特性（attribute）、关系和提取属性。

Managed Object 表示在运行时创建的该实体的具体实例。

实体和Managed Object间的关系等同于数据库中数据表与数据记录之间的关系。

 

以上内容参考自 http://www.cocoachina.com/iphonedev/sdk/2010/1126/2397.html 并做有修改。

转载于:https://www.cnblogs.com/yulang314/p/3551316.html