iOS开发之-Core Data-Managed Object Models

Managed Object Models

Features of a Managed Object Model

Entities

1. A model contains NSEntityDescription objects that represent the model's entities. Two important features of an entity are its name, and the name of the class used to represent the entity at runtime. You should be careful to keep clear the differences between an entity, the class used to represent the entity, and the managed objects that are instances of that entity.

2. An NSEntityDescription object may have NSAttributeDescription and NSRelationshipDescription objects that represent the properties of the entity in the schema. An entity may also have fetched properties, represented by instances of NSFetchedPropertyDescription, and the model may have fetch request templates, represented by instances of NSFetchRequest.

3. In a model, entities may be arranged in an inheritance hierarchy, and entities may be specified as abstract.

4. An entity maps a table in the database and maps to an object in your code.

Entity Inheritance

1. Entity inheritance works in a similar way to class inheritance, and is useful for the same reasons.

Abstract Entities

You can specify that an entity is abstract—that is, that you will not create any instances of that entity.

Properties

1. An entity's properties are its attributes and relationships, including its fetched properties (if it has any). Amongst other features, each property has a name and a type. Attributes may also have a default value. 

2. Transient properties are properties that you define as part of the model, but which are not saved to the persistent store as part of an entity instance's data. Core Data does track changes you make to transient properties, so they are recorded for undo operations.

Attributes

1. An attribute maps a column in the database and maps to a property in our object.

You can specify that an attribute is optional—that is, it is not required to have a value. In general, however, you are discouraged from doing so—especially for numeric values. The reason for this is that SQL has special comparison behavior forNULL that is unlike Objective-C'snil.NULL in a database is not the same as0, and searches for0 will not match columns withNULL.

Relationships

1. The to-many relationship maps to an (NSSet *) property in our object. 

Core Data supports to-one and to-many relationships, andfetched properties. Fetched properties represent weak, one-way relationships. 

You can specify the optionality and cardinality of a relationship, and its delete rule. You should typically model a relationship in both directions. A many-to-many relationship is one in which a relationship and its inverse are both to-many. 

Managed Objects

Basics

Managed objects are instances of the NSManagedObject class, or of a subclass of NSManagedObject, that represent instances of an entity. You might implement a custom class, for example, to provide custom accessor or validation methods, to use non-standard attributes, to specify dependent keys, to calculate derived values, or to implement any other custom logic.

A managed object is associated with an entity description (an instance of NSEntityDescription) that provides metadata about the object and with a managed object context that tracks changes to the object graph.

A managed object is also associated with a managed object context (“context”). In a given context, a managed object provides a representation of a record in a persistent store. In a given context, for a given record in a persistent store, there can be only one corresponding managed object, but there may be multiple contexts each containing a separate managed object representing that record. 

Properties and Data Storage

1. In some respects, an NSManagedObject acts like a dictionary—it is a generic container object that efficiently provides storage for the properties defined by its associated NSEntityDescription object. There is therefore commonly no need to define instance variables in subclasses. 

2. By default, NSManagedObject stores its properties as objects in an internal structure, and in general Core Data is more efficient working with storage under its own control rather using custom instance variables.

Custom Managed Object Classes

Modeled Properties

Core Data dynamically generates efficient public and primitive get and set attribute accessor methods and relationship accessor methods for properties that are defined in the entity of a managed object’s corresponding managed object model. Typically, therefore, you don’t need to write custom accessor methods for modeled properties.

Since Core Data takes care of the life-cycle of the modeled properties, in a reference-counted environment you do not release modeled properties in dealloc. (If you add your own properties that are not specified in the managed object model, then normal Cocoa rules apply.)

Object Life-Cycle—Initialization and Deallocation

It is important to appreciate that Core Data “owns” the life-cycle of managed objects. With faulting and undo, you cannot make the same assumptions about the life-cycle of a managed object as you would of a standard Cocoa object—managed objects can be instantiated, destroyed, and resurrected by the framework as it requires.

In a typical Cocoa class, you usually override the designated initializer (often the init method). In a subclass of NSManagedObject, there are three different ways you can customize initialization —by overriding initWithEntity:insertIntoManagedObjectContext:, awakeFromInsert, or awakeFromFetch.