Re: Design Question: Pro & Cons of KVC/KVO
Re: Design Question: Pro & Cons of KVC/KVO
- Subject: Re: Design Question: Pro & Cons of KVC/KVO
- From: Negm-Awad Amin <email@hidden>
- Date: Thu, 21 Aug 2008 17:27:45 +0200
Am Do,21.08.2008 um 17:03 schrieb Oleg Krupnov:
Amin,
It is true that I am new to Cocoa, and although I find the
documentation really great and engaging, I have sort of difficulty
figuring out what technology is newer/more powerful/built on top of/
other technology.
In particular, would you explain me, in just two words, what are the
relations between and intended/typical applications of
(in the context of implementing the MVC pattern)
1) KVC/KVO
KVC is a very old (10.0?) technique to set properties of an entity. In
comparison with setters you can choose (change) the property at run-
time without changing your code:
Entity* instance = …; // imagine this is set
[instance setProperty:value]; // you know that
You cannot change the name of the property without recompiling. This
can be done with KVC:
NSString* key;
Entity* instance = …; // imagine this is set
key= @"property";
[instance setValue:value forKey:key];
key= @"another";
[instance setValue:value forKey:key];
Since key is a NSString constructed at run-time, you can change the
property at run-time.
KVO is newer, I think 10.3 IIRC and something totally different: The
core: You get a mesage, if you registered for a property of an
instance, that changes. It's quite close to your code. There are
differences between automatic and manual KVO, but this is the essence.
2) Bindings
Bindings use KVO to get synchronized and KVC for reading/writing data.
You can imagine a binding a command to an object, to observe the given
key of the given instance. So, hmmm, usually an object starts a KVO,
when it becomes bound. Conceptionally:
- bind:(NSString*)boundPropertyKey toObject:(id)observed forKeyPath:
(NSString*)observedProperty
// start KVO
[observed addObserver:self forKeyPath:observedProperty];
There are more features through binding options I omitted to clarify.
KVO, KVC, and Bindings are placed "between" the MVC-layers. They
typically synchronize a controller to the model and a view to the
controller. (Inside a layer you typically do not need KVO, KVC,
because the objects inside the same layer know each other. But of
course you can use KVO, KVC)
3) Core Data
Core data is not neccessarily related to KV*. It is simply a
technology for your model to ease the boring work of defining entites,
writing accessors, supporting serialization….
But core data is KVC- and KVO-compliant, that means, that you can set/
read properties to/from an core data entity and you're able to observe
the properties. Short: You *can* use KV technologies with core data.
Using core data or not and using KV* or not is orthogonal.
4) Anything else I may have overlooked?
If Core Data is really that cool, why don't one always use it instead
of KVC/KVO or maybe Bindings?
See above. You do not use core data or KV*, but core data and KV*
BTW I didn't say I thought Core Data was a database, I said it may be
intended rather for database apps.
Okay :-)
The usage is quite simple (if I'm allowed to simplify that)
Without core data
In your model you have classes for entities, let's say Person,
Department, Company, Account … These classes are typically subclsses
of NSObject. So you have to define the ivars, write accessors (okay,
Objctive-C 2 …), maybe support undoing, support serialization with
NSCoding …
With core data
In many cases you do not need any subclass, but simply use
NSManagedObject. The definition of the model can be done in the
modeller very easy. Undoing, Coding and so on will work.
Cheers
Amin Negm-Awad
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden