Database Reference
In-Depth Information
1.4
NSManagedObject
The
NSManagedObject
is the object we work with the most in a Core Data appli-
cation. Each instance of the
NSManagedObject
represents one entity in our Core
Data repository. By combining Core Data with KVO and KVC (discussed in
great detail in
Chapter 8,
OS X: Bindings, KVC, and KVO
, on page 137
), this
one object can dynamically represent any object that we need and that can
be defined in our data model.
All of the properties and relationships defined in our data model are available
and are easy to access directly from the
NSManagedObject
. Without subclassing
it, we can access values associated with an
NSManagedObject
in the following
ways.
Accessing Attributes
Attributes are the easiest to access. By utilizing KVC, we can get or set any
attribute on the
NSManagedObject
directly. If you have reviewed our sample app
in
Appendix 1,
Building a Foundation
, on page 209
, you may have noticed that
we did not write a
Recipe
class. At this point in our application, the
NSManage-
dObject
provides all of the functionality that we require. For example, we could
get the name as follows:
NSManagedObject *recipe = ...;
NSString *name = [recipe valueForKey:@
"name"
];
Likewise, we can set the name in a similar fashion, as follows:
NSManagedObject *recipe = ...;
[recipe setValue:@
"New Name"
forKey:@
"name"
];
When we want to subclass
NSManagedObject
, we can also define properties for
the attributes (and relationships discussed in a moment) so that we can access
them directly. In the header of our subclass, we would define the properties
normally.
@interface
PPRRecipeMO : NSManagedObject
@property
(strong) NSString *desc;
@property
(strong) NSString *imagePath;
@property
(strong) NSString *lastUsed;
@property
(strong) NSString *name;
@property
(strong) NSString *serves;
@property
(strong) NSString *type;
As you can see, we are defining the property like normal, but there are no
ivars
associated with those properties. Since these properties are created