Re: ADC Core Data article
Re: ADC Core Data article
- Subject: Re: ADC Core Data article
- From: mmalcolm crawford <email@hidden>
- Date: Wed, 6 Apr 2005 00:52:54 -0700
On Apr 5, 2005, at 11:22 PM, Paul Szego wrote:
On 06/04/2005, at 2:48 PM, Will Mason wrote:
On the other hand, if you don't need all these services and just aim
for persistence, CoreData aren't what you need: just use an
NSArchiver, and you get the support for any NSObject :))
No, you don't. An object can be archived (sent to/read from an
NSCoder)
only if it adopts the NSCoding protocol.
A similar approach for CoreData would be better. Having a base
class that implements this for free is a good thing, as long as
that's not the only way to do it. Hopefully you wont be forced to
extend a specific base class - that's just bad design.
The article is very clear:
"By default, the class used is NSManagedObject, but the class may be
either NSManagedObject or a subclass thereof."
If Core Data only addressed object persistence, then it might be
argued that this would be poor design. As noted earlier, however, it
also solves a much more difficult problem, and one that really only
affects data objects. Given the functionality that's provided for
free, requiring that your model classes inherit (ultimately) from
NSManagedObject instead of NSObject does not seem too onerous (I
suspect in most cases this will simply involve adding 7 characters to
your declaration...).
Indeed it's reasonable to argue that putting all the functionality of
a model object into the root class would be bad design. It would add
an unnecessary overhead to all the other system classes, from views
to controls to strings (which don't need to know what entity they
represent or what context they belong to(*))...
mmalc
(*) "In order to be properly managed, a data object needs to be
associated with its managed object context and an entity definition
that is part of the managed object model that is being implemented by
the context."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden